Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
On Thursday, June 02, 2011 05:11:30 AM Goswin von Brederlow wrote:
> 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.
I agree that 3.0 (quilt) has a lot of advantages. I don't find though that 1.0
packages are particularly difficult to deal with as a rule. Most of them either
use no patch system (which I dislike for the same reason I don't like 3.0
(quilt) applying patches by default) or quilt. Sometimes I hit packages that
still use dpatch or the CDBS simple patchsys. These are easy enough to deal
with using *-edit-patch. Then there are a few odd cases that are difficult, but
they are rare. So I agree that they aren't consistent, but in practice this
is easy enough to deal with.
When making a new package with modern DH based rules integrating quilt into a
package is trivially simple, so ease of having quilt as your patch system
really isn't an argument for 3.0 (quilt).
If 3.0 (quilt) didn't apply patches by default I'd have no reason not to just
use it. Keeping local_options in a VCS is a bit of a workaround for this, but
it seems wrong to have a persistent diff between what's in the VCS for a
package and what's in the archive. I'd really like to have a way to just
control this globally on my system.
Scott K
Reply to: