Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Scott Kitterman <debian@kitterman.com> writes:
> On Wednesday, June 01, 2011 10:26:59 AM sean finney wrote:
>> On Wed, Jun 01, 2011 at 02:39:42PM +0200, Goswin von Brederlow wrote:
>> > And note that as maintainer or for the VCS copy you can allways
>> > configure debian/soruce/local-options to unapply patches if you so
>> > desire.
>>
>> This is something i've been doing quite happily and I think it is
>> a pretty decent compromise for the user/maintainer use cases.
>>
>> If you're building from the VCS there may be a difference in behavior,
>> but if you build a downloaded source package (or even a source package
>> generated from the VCS), the behavior is consistant.
>
> I tend to touch many packages and only revisit them infrequently so I don't
> generally have a local copy of the package to have modified when I start work.
> So for me the general workflow for using debian/source/local-options would be
> something like:
>
> download package/check out fom VCS
If it is from VCS and the workflow is with patches not checked in then
why isn't there a debian/source/local-options already?
> oh, this is V3
> unapply patches
> add debian/source/local-options
> work on package
Oh, this isn't a V3 packages. Read README.source, read debian/rules,
read manpage of strange patch system, run debuild and read the log to
figure out how this black box patches its source, .... Works both ways.
Note that you do not need to unapply patches or care about them at all
to work on the package. So if you are doing an NMU or preparing a patch
for the BTS then it is just:
apt-get source foo
work on package
debuild
test
# 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)
With 1.0 packages you frequently first have to learn about the patch
system used before you can alter and build the package. That I think is
the greatest benefit of 3.0 (quilt): For the simple case of quickly
fixing a bug it is transparent and just works out of the box.
> apply patches if needed
That is never needed as building does that as needed. Unless you mean
going up and down the patch series while you work on the package. That
you have with 1.0 + patch system as well. No change then.
> upload
> rm -fr the package
>
> debian/source/local-options doesn't really help me much Not making the
> package source format 3 on the other hand conveniently provides the workflow I
> want in a persistent manner with no recurring effort needed.
>
> Scott K
Hardly persistent. Half the packages will have stuff pre-applied from
the diff.gz, half the packages will have $random patch system and the
third half :) will even mix the two.
I'm not saying 3.0 (quilt) is the ultimate format and I'm not saying
nobody should still use 1.0. But please don't call the 1.0 packages we
have in the archive consistent. If you just mean your own packages then
you could change them all to have debian/source/local-options in their
VCS too. If you mean other peoples packages then I don't see how you can
claim they behave in any persistent manner.
I think 3.0 (quilt) made a great step towards unifying the packaging of
most of the 1.0 packages with a patch system. Nearly all of those can be
easily changed to 3.0 (quilt) format to get a simple to use, flexible
(for the maintainer) and uniform (for the user) behaviour. Not all of
them but that is ok.
MfG
Goswin
Reply to: