Hi!
Quoting a paragraph from: http://lwn.net/Articles/283030/
Debian's packaging policy resembles that of most other distributions. A Debian source package is supposed to contain a tarball of the upstream source distribution, without changes. Any distribution-specific patches are included separately and applied when the source package is prepared for building.
Do we have a policy that all patches we apply in our packages need to be included *separately*? (I couldn't find anything like that in our guidelines, but maybe I missed it) And if not: Do we want such a statement in our guidelines?
Background: I wanted to use grub as provided by Fedora on a FAT partition. That didn't work properly, as the Fedora grub includes this patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-7/grub-0.93-configfile.patc...
The main part of it (¹):
- .string "/boot/grub/menu.lst" + .string "/boot/grub/grub.conf"
That of course creates trouble, as FAT due to its 8.3 filemane limitations can't store a file called grub.conf. Thus I had to build a special grub where this patch wasn't applied. That was no big deal and at least for me a easy thing to do.
In F8 and later that's way harder, as there is one patch (created from git afaics) where all the patches that in F-7 were applied separately are now merged into one giant 1,6 MByte big patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-8/grub-fedora-8.patch?view=... Building grub without that one patch of course is way harder now, as I need to get my hands on that one patch and revert it after the giant patch was applied. Not impossible, but way harder if one doesn't know where to find that one small patch to revert it.
Do we care or do we want to ignore this (minor) issue?
CU knurd
(¹) Side note: I think it's wrong to add such a patch, as differing from upstream in things like config file naming just creates trouble and confusion for everyone.
On Wed, 2008-05-21 at 08:31 +0200, Thorsten Leemhuis wrote:
Hi!
Quoting a paragraph from: http://lwn.net/Articles/283030/
Debian's packaging policy resembles that of most other distributions. A Debian source package is supposed to contain a tarball of the upstream source distribution, without changes. Any distribution-specific patches are included separately and applied when the source package is prepared for building.
Do we have a policy that all patches we apply in our packages need to be included *separately*?
None that I am aware about, except that we ask/encourage packagers to use clean upstream tarballs.
As a consequence of this, we have a similar rule in effect.
Do we care or do we want to ignore this (minor) issue?
IMO, we should.
(¹) Side note: I think it's wrong to add such a patch, as differing from upstream in things like config file naming just creates trouble and confusion for everyone.
Agreed. Shipping customized tarballs, where an upstream is available should be banned.
Ralf
Thorsten Leemhuis wrote:
Hi!
Quoting a paragraph from: http://lwn.net/Articles/283030/
Debian's packaging policy resembles that of most other distributions. A Debian source package is supposed to contain a tarball of the upstream source distribution, without changes. Any distribution-specific patches are included separately and applied when the source package is prepared for building.
Do we have a policy that all patches we apply in our packages need to be included *separately*? (I couldn't find anything like that in our guidelines, but maybe I missed it) And if not: Do we want such a statement in our guidelines?
AFAIK, Debian is worse off than we are here. dpkg itself can only take a single patch file. Many Debian maintainers keep separate patches in their source tree but those are changed into a single patch by the time the .deb is built.
The lwn article probably means "separately" as in "separate from the tarball".
Background: I wanted to use grub as provided by Fedora on a FAT partition. That didn't work properly, as the Fedora grub includes this patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-7/grub-0.93-configfile.patc...
The main part of it (¹):
- .string "/boot/grub/menu.lst"
- .string "/boot/grub/grub.conf"
That of course creates trouble, as FAT due to its 8.3 filemane limitations can't store a file called grub.conf. Thus I had to build a special grub where this patch wasn't applied. That was no big deal and at least for me a easy thing to do.
In F8 and later that's way harder, as there is one patch (created from git afaics) where all the patches that in F-7 were applied separately are now merged into one giant 1,6 MByte big patch: http://cvs.fedora.redhat.com/viewcvs/rpms/grub/F-8/grub-fedora-8.patch?view=...
IIRC the history of grub is that only distributions care about the current stable release of grub. Upstream has been working on the next release only but it's not ready yet. This could be why we've switched from multiple patches to a single patch from source control... it's essentially a fork at this point.
Building grub without that one patch of course is way harder now, as I need to get my hands on that one patch and revert it after the giant patch was applied. Not impossible, but way harder if one doesn't know where to find that one small patch to revert it.
Do we care or do we want to ignore this (minor) issue?
I think we should care. We probably want something like:
'''SHOULD''': Packages should keep patches that are only meant for Fedora (config changes, hacks to work around problems until a real answer is found) separate from packages suitable for upstream (bugfixes, enhancements, things that should be sent upstream).
Alternately, this could be tied with the patch metadata-upstream policy that's in the works (as the primary metadata info is what's the status of this upstream).
I'm not sure how this would apply to grub if my understanding of its history is accurate. Perhaps there needs to be an upstream project created for our fork.
-Toshio
packaging@lists.fedoraproject.org
-
Ralf Corsepius -
Thorsten Leemhuis -
Toshio Kuratomi