Patch systems in packages

[Emmet Hikory]

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

    I think you miss my point entirely, as I agree with the assertion
that "[the] work of detangling multiple patches is so large as to be
nearly insurmountable unless each patch is a simple one or two
liner.", which is precisely why I argue against the introduction of a
patch system in cases where the patches are maintained directly in the
diff.gz in Debian: I claim it is simpler for an Ubuntu merger to
review an additional small patch maintained in the diff.gz (or even
two).  Where the package has been repackaged and the patches stored in
Debian in the diff.gz pulled into separate patches (perhaps correctly,
perhaps not, depending on the available documentation and the skill of
the person extracting the patches from the diff.gz), it directly
complicates the work of the Ubuntu merger to understand what was
changed in the diff.gz in Debian and how to integrate that into the
patch system.  This is well after one has "[lost] control of what
patches have been applied, what they do, and why they were needed, and
how they work" within the diff.gz.  If I take as an example the recent
merge of dibbler (1): consider the case where the Debian maintainer
may in future make two unrelated changes that happen to touch the same
single file in the diff.gz.  How is the Ubuntu merger to handle that?
Are they to detangle these changes in order to fit them into the
introduced patch system?  Are they to create a new
debian/patches/debian_random_changes.dpatch to contain them?  Would it
not have been simpler *for the Ubuntu merger* to have the meaningful
1-line patch also stored in the diff.gz?  While storing it there does
require a slightly more verbose changelog entry to make sure that the
patch is understood, it seems to be less likely to cause issues in the
future, especially as the merger in one cycle may well not be the
merger in the next cycle.  The advantage of minimising the monolithic
debdiff as presented on the PTS is not only for the Debian maintainer,
but also for the Ubuntu merger who is trying to understand what
changed, and where, and why.

    I am not advocating the storage of patches in the diff.gz, as I
believe that this makes the package awkward to extend when Ubuntu
seeks to add patches: I'd much prefer that each package have a patch
system.  I understand that for work in Debian, using a VCS in place of
a patch system can be easier, but it's certainly not easier for
derivatives, especially for patches that do not belong back in Debian.
 Rather I am arguing against the introduction of a patch system in
Ubuntu for packages that maintain patches in the diff.gz in Debian
except in the rare case where there is such a vast separation in the
Ubuntu and Debian packaging that it becomes easier to apply Debian
patches by reviewing debdiffs between Debian packages rather than
either using the merge tools or rebasing packaging off the Debian
package each time.

1: https://lists.ubuntu.com/archives/intrepid-changes/2008-August/005755.html

-- 
Emmet HIKORY