Patch metadata (Was: Plan for tomorrows (20080424) FESCO meeting)

Kevin Kofler kevin.kofler at chello.at
Thu Apr 24 06:17:52 UTC 2008


Colin Walters <walters <at> verbum.org> writes:
> The problem I'm trying to solve is when people collaboratively
> maintain a package, you want to know when e.g. updating to a new
> upstream version what the upstream status of patches are so you know
> whether to expect to see them in the new tarball.

Why do you want to make this mandatory then? Some packages have only one 
maintainer, some have multiple maintainers who have managed to handle this 
issue just fine.

It's fairly easy anyway to figure out whether a patch has already been applied 
upstream: try building with the patch, if it fails with "patch reversed or 
already applied" in the build.log, drop the patch, make force-tag, resubmit. 
That or directly check the upstream VCS. I'm going to have to do that anyway 
because the comment above the patch might be outdated, e.g. in projects like 
KDE where upstream may decide to backport a patch from trunk to the release 
branch at any time (and as we obviously ship releases, not trunk snapshots, 
what's on the release branch is what really matters, a "this has been 
upstreamed in trunk and maybe some other branches" comment isn't very useful).

How we're currently handling this in the KDE packages is that we use patches 
100 and above (with an "upstream patches" comment) for patches which come from 
upstream and 0 to 99 for our own. However, the patches in 0 to 99 could have 
been upstreamed since, and for the upstream patches, they could be coming from 
any branch, so the usefulness for the use you're envisioning is limited.

        Kevin Kofler




More information about the fedora-devel-list mailing list