Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Guido Günther <agx@sigxcpu.org> writes:
> 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:
It automatically tracks what you've changed every time you build a
source package. That part is automatic.
Splitting the changes into suitable patches is another matter. The
easiest is to work on one thing at a time and rename the automatically
generated patch after each. If you do it all at once then you have to
split the resulting mess yourself.
But that is no worse than getting all the changes in the diff.gz and
having to split that into suitable patches.
> 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
Yes. Evil attempt to do some product placement. :)
MfG
Goswin
Reply to: