Patch systems in packages

[Emmet Hikory]

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?

> 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.
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.  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).

-- 
Emmet HIKORY