Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
* Raphael Hertzog <hertzog@debian.org> [110529 10:53]:
> I see 2 ways to solve this:
> a/ detect the common VCS and make --unapply-patches the default in that
> case (but it would require a --no-unapply-patches for the people who
> keep the patches applied in their VCS)
I'd be very disappointed if the more consistent way of having patches
applied in vcs would be punished this way just because some 'majority'
uses their vcs like svn was still state of the art.
> 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.
That sounds a bit better, but it adds even more magic to dpkg-source.
I really miss some way to express: "In this account, do not use magic.
If things are not correct and need fixing, tell me what is wrong and
abort so I'll never miss it." (Actually I'd prefer it as default and
only have it enabled by some options, but a way to globally disable
and turn them into hard errors would would be good enough[tm].)
> 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.
There is still no way to get this behaviour account-wide, is there?
> I wonder if I should not make this option the default and fail with an
> error messages suggesting that the maintainer should run "dpkg-source
> --record-changes" if he really wants to keep the current changes. It
> would also leave the diff around somewhere in $TMPDIR if the user wants
> to review it.
Sounds nice.
Bernhard R. Link
Reply to: