Patch systems in packages

[Phillip Susi]

Emmet Hikory wrote:
>> 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?

You just answered your own question.  The Debian Maintainer does not
want to see a monolithic patch that includes all of the debianization
and changes already there in the debian package.  He just wants the one
new patch you have added, broken out on its own.  Tracking the patches
independently is useful to everyone who wants the patches to remain easy
to maintain.

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

Yes, there should be no changes in the .diff.gz outside of debian/ ( at
least when not using a proper VCS ).

> 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

That's exactly WHY all changes to the original sources should be done
via a patch system; so that it is immediately clear when you are
changing the debian changes, or applying a patch to the upstream source.

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

VCS throws a big wrench it the works since it totally clashes with the
debian package system, which essentially is another form of VCS.  If you
are using a VCS, then you have to stick to the external VCS and not
bother with directly messing with the debian source package.  If you
aren't using an external VCS, then you handle change control the debian
way and use a patch system.