Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
On Thu, Jun 02, 2011 at 11:11:30AM +0200, 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)
The problem is that you don't have an underlying VCS here so it's hard
to track what you've changed and split patches when doing more complex
changes. So I'm usually using:
git-import-dsc --download <package>
# If you want to unapply patches after the build:
/usr/share/doc/git-buildpackage/examples/gbp-configure-unpatched-source
which puts the package in a git repo with all the "git add -p/git
checkout -f/git format-patch" features. But that's probably slightly of
topic.
Cheers,
-- Guido
>
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 877h94bnst.fsf@frosties.localnet">http://lists.debian.org/[🔎] 877h94bnst.fsf@frosties.localnet
>
Reply to: