[Fedora-packaging] shipping distribution-specific patches *separately*

[Toshio Kuratomi]

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