[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches



Hi Raphaël,

Thanks for looking at ways to improve the dpkg-source experience.

On Sun, May 29, 2011 at 10:53:03AM +0200, Raphael Hertzog wrote:
> b/ modify dpkg-source --before-build to keep a trace of the fact that
>    it applied the patches (for example by creating
>    .pc/dpkg-source-auto-applied) and in that case have dpkg-source
>    --after-build unapply the patches so that we're back to a clean
>    state after a succesful build.
>    If the build fails, we'd keep the patches applied.

> My preference goes to b/ because it doesn't require changes for people
> who like to keep the patches applied in their VCS too. And it's the
> principle of least surprise, you keep the same state afer a build than
> you had before the build (so it's still ok for people who rely
> on the scenario unpack/hack/rebuild).

> Comments? Does this look reasonable?

That sounds perfectly reasonable to me.

> Again to cope with the scenario explained at the start of this mail,
> once a user has made modifications we must ensure that they end up in a
> proper patch in debian/patches/. Right now this is entirely automatic,
> the generated patches take the form of
> debian/patches/debian-changes-<ver>.

> Obviously this is a pretty poor name for a patch and given it's
> automatically generated, it doesn't contain much useful description.
> In general they are renamed by the maintainer who also adds a
> description (or they are properly put in place before the build so that
> dpkg-source doesn't have to create it).

> But it still happens that those patches are generated[1] when the maintainer
> did not expect any change at all. That's why we added the option
> --abort-on-upstream-changes for maintainers who never wants dpkg-source
> to auto-create a patch.

For me, what's most annoying here is the use of the version number in the
patch name.  This means, for instance, that if the clean target modifies the
contents (maybe by regenerating configure), each package version could
create a *new* patch for something that should definitely be represented as
part of a single patch.

I'm inclined to think that --single-debian-patch is a more directly useful
default (possibly without --abort-on-upstream-changes).  It doesn't give the
best results for patch naming and headers, but if the maintainer is actually
going to put in the effort to do all that, I would assume they can change
the default anyway.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: