Patch systems in packages

[Phillip Susi]

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

That's why you don't send the debian maintainer the debdiff.  You send 
him the individual patch(es), and let him worry about applying them 
using whatever patch system, or lack of one, that he chooses.  Even if 
he looks at the debdiff, picking out the individual patches is trivial, 
at least with dpatch.

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

I agree with that.  If you try to send the debdiff to the debian 
maintainer it will be frustrating to him.  This is easily solved though 
by just sending him the patch instead.  While it is good to be concerned 
about debian, maintaining the package in ubuntu is more important, and 
doing so requires a reasonable patch management system.  It seems you 
are trying to make it trivially easy for a debian dev to import a 
trivial patch from an ubuntu derivative at the expense of making 
maintaining the ubuntu package much more difficult.

>     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

I generally agree, but what seems a single, simple, small change at the 
time can easily grow more complicated quickly, so it's a good idea to 
start using a VCS or patch system with the first change, so you don't 
have to add it later.

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

I disagree vehemently with this point.  The work of detangling multiple 
patches is so large as to be nearly insurmountable unless each patch is 
a simple one or two liner.  Even if you can figure out what changes 
correspond to what entry in the changelog, usually the changelog 
description is far more terse than the one accompanying the patch, which 
you can not recover if it is just merged into the main .diff.gz.  While 
adding a patch system makes the diff larger, it is generally pretty 
standard stuff, and so easy to filter out.  Even scanning the debdiff by 
eye, it is very simple to pick out the one or two dpatch files that were 
added from the boilerplate code, and easily review or separate them.

If it is a single and very simple patch that requires little 
explanation, then it isn't so bad to leave it in the .diff.gz, but as 
soon as you start carrying multiple patches, or patches which are 
somewhat complex, you really need to use a VCS or patch system to track 
each change independently and with good descriptions, or you will 
quickly loose all control of what patches have been applied, what they 
do, and why they were needed, and how they work.