Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Charles Plessy <firstname.lastname@example.org> writes:
> Le Thu, Jun 02, 2011 at 11:11:30AM +0200, Goswin von Brederlow a Ã©crit :
>> apt-get source foo
>> work on package
>> # Optionally: Just to be nice and fill out the header
>> # This would be improved by the --record-changes discussed earlier
>> edit debian/patches/debian-changes-version
>> reportbug -A debian/patches/debian-changes-version foo
>> (upload NMU)
> Hi Goswin,
> this is how a change of a couple of characters become a much larger patch. See
> for instance the following, which I have received in #606004 (not a NMU).
> 64 lines of patch for one line changed in examples/Makefileâ?¦
That is what happens if you blindly send a debdiff. Also no change
compared to a 1.0 + patchsystem package. The debdiff for 1.0 + quilt
would look exactly the same. For dpatch too iirc, or maybe 5 lines less.
The right thing to do would have been to fill out the patch header
properly and send just the patch. For both 1.0 and 3.0 format.
> I see that debcheckout now has a --source option with â??autoâ?? as a default
> value, to â??retrieve the remaining parts of the source using apt-get source and
> move the files into the checkoutâ?? when only the debian directory of a package
> is managed in a VCS. In parallel, the most used patch systems honor the Debian
> Policy's Â§4.9 by providing a â??patchâ?? target for debian/rules. So for many
> packages, there is actually a quite uniform entry point.
> When working on actively maintained packages, I think that using debcheckout
> and committing the changes is more efficient as a whole.
In which case you get the debian/source/local-options and the proper
patched or not patched behaviour depending on what the VCS system
workflow is using. So again. It makes no difference wether it is 1.0 or
3. format in that case.