Patch systems in packages

[Steve Langasek]

On Wed, Aug 20, 2008 at 11:31:41AM +0900, Emmet Hikory wrote:
> Steve Langasek wrote:
> > If you have more than one change to the upstream source of a Debian package,
> > then you need some system to manage the changes to indicate which parts of
> > the patch belong to which functional change -- i.e., a "patch management
> > system".  This can be a set of VCS feature branches, if you prefer (in which
> > case it's important to use the Vcs-* headers in debian/control in the Ubuntu
> > upload), or it can be an in-package patch system; but it is important to
> > have /some/ mechanism for labelling your changes so that you aren't left
> > with a single massive diff.

>     Why?  Why should the Debian Maintainer care about the monolithic
> patch as applied in Ubuntu (perhaps also cluttered by several
> changelog entries about merges that have happened, or rebuilds).  Is
> it not best practice to send those patches relevant to Debian to bugs
> in the BTS, as separated patches?  If this is done, to whom is it
> useful to track the patches independently, so long as the patches
> remain easy to maintain?

I think this is a misleading question:  it is /not/ easy to maintain patches
that are jumbled together in a monolithic diff, because even if it's easy
for the person who created the patches (which is likely to change over
time), it's not necessarily easy for $random_other_ubuntu_developer who
comes along afterwards.  Even the most innocuous-seeming of patches can
become head-scratchers over time if they aren't accompanied by appropriate
metadata (description, + some sort of bounding box saying which bits
belong).

So for *Ubuntu's* benefit, I believe our best practices should be to use
some sort of patch management whenever patching upstream sources, not just a
monolithic diff.  (Again, I think this can be either VCS feature branches or
an in-package patch system, whichever is easier for the people doing the
work.)

> > If the Debian maintainer already has a patch system in place, it's far
> > better to continue using that one (no matter how bad it is, sometimes);
> > otherwise, adding a patch system *should* be done when needed.

>     I generally argue against the introduction of patch systems, as 1)
> I am very much opposed to working with a package that has both changes
> in diff.gz (from the original packaging), and 2) a patch system.

If we're talking about packages where the Debian maintainer has already
patched upstream and done so without a patch system, then I agree that this
is ugly; in that case I think the best outcome is if the Debian maintainer
can be persuaded to /use/ some form of patch management.

> These are painfully ugly, and the monolithic diff frequently becomes
> completely unreadable (was this a change to a previous Debian change,
> to an upstream change, or to a combination?); and 2) I have heard a
> number of Debian maintainers complain about the "useless" introduction
> of a patch system when they maintain the package in a VCS with no
> patch system.

Can you give examples of these?  Ideally if the maintainer is already using
feature branches in a distributed VCS, Ubuntu could hook into that with its
own feature branches, and that would entirely satisfy my concerns about
maintainability of the patches.  But the highest percentage of Vcs-* fields
in Debian packages still point at subversion, which is not at all useful for
this purpose.

> That said, in the case where there are no previous diff.gz changes
> external to debian/, I think it is best practice to review other packages
> with the same Debian Maintainer to attempt to determine the preferred
> patch system of that maintainer (which may be monolithic diff.gz), and
> follow that practice.  In the rare case where there are no patches
> external to debian/ in any of the packages maintained by that Maintainer,
> the introduction of a patch system seems the least bad way to do things,
> but this is very much an exceptional case, and for most packages we would
> do well to instead follow the existing practice (even where that is a
> monolithic diff.gz).

I agree; I was assuming the common case was that the Debian package did not
include patches to the upstream source, or that if there were any such
patches, they were managed with a patch system.  Perhaps this is not such a
common case as I believed.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org