Re: How to cope with patches sanely
Le Tue, Feb 05, 2008 at 02:16:09PM +0200, Lars Wirzenius a écrit :
> Specifically I want "dpkg-source -x" to unpack a source package so that
> it is ready for modification, and "dpkg-source -b" to build a new source
> package after it's been edited. Patch systems can and should conform to
> that, since it's important for those doing archive-wide QA.
Hi Lars,
thank you for keeping us focused on the real problem. I have been trying
to think about it and still did not find an elegant solution. Suppose
that, as discussed earlier, "dpkg-source -x" provides source ready for
modification:
Case 1: It is because all the changes were in the diff.gz.
Case 2: It is because a clean way of applying the contents of
debian/patches has been developped and used.
In that case, unless "dpkg-source -b" has been similarly engineered to
turn the new changes into a new patch, things will fail when
"debian/rules clean" calls the unpatch rule and the changes overlap an
existing patch.
Case 3: It is because the sources have been packed patched.
In that case, "dpkg-source -b" is expected to work.
Now, let's remember the use case for these scenarii: it is when the
packages is modified for NMU or QA. If the NMU'ed package is to go back
in the hands of its maintainer (not MIA or so busy that he can not do
more than one upload per year, of course), as I wrote earlier, why not
simply send a diff in a bug report? Then the work overhead of
integrating the changes in the source package goes to the person who
chose the packaging workflow.
Otherwise, let's sees what happens with Cases 2 and 3. In Case 3, the
changes that you would make would be hidden in a diff.gz file that would
be bloated by design: it would already contain a mixture of
modifications to the source and patches shipped as patches to a patch.
For the maintainer, the most efficient tool to recover your changes from
this would be a debdiff with the old version, which then calls the
question of why just sending a diff instead of producing a new source
package would not be enough.
The easier scenario is of course the variant of Case 2 in which where a
automagic dpkg-source would take care of detecting the patch system and
turn your modifications into a new patch. But I have not seen any person
volunteer for working on such a modification.
So maybe the simplest solution would be the following :
- Standardize the name of the patch rule so that "debian/rules patch"
does the job.
- dpkg-source -b && debian/rules patch
- make a diff and send it to the BTS.
or, in the case of unmaintained packages:
- get rid of the patch system if you think that it is not good for QA
work on it.
It leaves the problem of trusting the command "debian/rules patch" when
working on non-official packages, but as I wrote before, the other
targets of debian/rules would have to be audited anyway, so why not
checking them first, and then run "debian/rules patch" ? (or decline to
sponsor the work of persons storing their changes in debian/patches).
Of course, I would be very interested to hear better solution, because
as I wrote, this one is not particularly elegant.
Have a nice day,
--
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan
Reply to: