Patch systems in packages

[Emmet Hikory]

Phillip Susi wrote:
> Emmet Hikory wrote:
>>    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.

    Actually, the monolithic patch that the Debian Maintainer
frequently doesn't want to see is the debdiff from the ubuntu version,
rather than the raw diff.gz.  This is presented by default on the PTS,
and can be useful for some packages, but is often not the best way to
see the results.  When there is a simple patch, this debdiff can be
clean, regardless of how the patch is applied.  When a patch system is
introduced in Ubuntu to a package that does not have a patch system in
Debian, this debdiff will be less clean, and if the patch system
chosen in Ubuntu is not one preferred by the Debian Maintainer, it
means that the fix requires more than just applying the patch after
filtering out the changelog and maintainer change.  More generally, if
the Debian Maintainer uses e.g. quilt, this debdiff ought contain a
quilt-formatted patch: the same ought be true for packages using
simple-patchsys, dpatch, a custom-hacked patch system in debian/rules,
or changes raw in diff.gz.

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

    This is precisely not what I am saying.  When a package is
introduced in Debian, I agree with you completely.  When a package
that uses a VCS in Debian and stores patches in diff.gz, I do not
believe it is appropriate for Ubuntu to introduce a patch system.
This either results in a package that makes changes external to
debian/ in both the diff.gz and a patch system, or requires that the
diff.gz changes be unwound to work with a patch system.  In cases
where the package assumes that the patches will be applied before
running debian/rules clean, this can be especially confusing and turn
what ought to have been a simple patch into a long and complicated
repackaging process.  It is a far superior model to follow the
practice of the existing source package and send the patch of interest
to the BTS for individual tracking.

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

    How does this become differently clear?  If the package in
question uses a patch system in Debian, then there is no debate.  If
the package in question does not use a patch system in Debian, the
introduction of a patch system and attendant repackaging may appear to
be a voluminous change to the Debian changes (and is), while the
actual patch of interest was an upstream patch exclusively.  I submit
that changing the choice of patch system (or none) is significantly
more frustrating to a Debian Maintainer than applying a patch
following the practice used in Debian.

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

    If we're talking about Debian, again I agree with you entirely.
On the other hand, we're talking about Ubuntu, and not all changes
made in Ubuntu are appropriate to go in the Debian VCS, nor do the
parties changing the Ubuntu package necesarily have permission to
write to that VCS.  Again, to me, it seems least painful to follow the
previous Debian practice (whatever that may be), and if the patch is
of interest to Debian, send that patch to the BTS for separate review
by the Debian Maintainer.  Yes, this may complicate the later merge if
the code patched is also changed in a different way, but our merge
systems are fairly good, and the changelog should provide a hint as to
whether the associated BTS entry was closed (and yes, this may require
actualy reviewing the bugs closed by the outstanding Ubuntu changes,
but I fail to see how this is a bad thing).

    All of the above notwithstanding, I do agree with Steve that where
there are a significant number of Ubuntu changes, especially where
many of them are not expected to go to Debian, it makes sense to track
the patches in Ubuntu, rather than in the Debian BTS.  In these cases,
I think it's appropriate to use a patch system if present, branch a
VCS if Debian code is in a VCS and no patch system is present,
introduce a patch system matching the Debian Maintainer's apparent
preference, or introduce a new patch system in Ubuntu, with preference
in that order.  On the other hand, I don't think this overhead is
necessarily worthwhile for something small for a package well
maintained in Debian and for which the patch is useful to Debian.  In
these trivial (but very common) cases, the work for a later Ubuntu
merger to discover that the patch system and attendant patches are no
longer relevant is of similar volume to that of an Ubuntu merger
presented with a couple of patches in diff.gz that must be detangled,
and yet the volume of work to put the pacakge in this state is
considerably higher, so the total volume of work for Ubuntu is larger.

-- 
Emmet HIKORY