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.patch?view=markup
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=markup
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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
