Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Hello,
from time to time I hear some rumblings about how "3.0 (quilt)" mixes
badly with VCS. Indeed, one of the primary goals of the format
was to not require prior knowledge of the patch system to be able to
modify a package. And it's the case since you can do:
- dpkg-source -x
- modify files
- debuild
But there are a few downsides:
Auto-application of patches
---------------------------
Since dpkg-source -x auto-applies the patch, the build part was
designed with the assumption that patches are pre-applied and this
assumption is often wrong for people using VCS. I have resolved this
by auto-applying the patch at the start of a build but (some) users of VCS
have been annoyed with it because it left the VCS unclean after the
build. The option --unapply-patches has been added as a way to change
the behaviour (and you can put it debian/source/local-options).
I would like to improve this situation and not force the majority of
people to add the unapply-patches option (if it turns out the majority
of people use this option or are annoyed by the patches being applied).
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)
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?
Automatic patches
-----------------
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.
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.
It would break the initial scenario but since the solution is given in the
error message, I believe it would be acceptable.
"dpkg-source --record-changes <patch-name>" would be an interactive command
because you would be asked to fill the patch description header.
We still have the case of people who keep all their changes in the VCS
without maintaining debian/patches/ and who uses --single-debian-patch.
In that case, --abort-on-upstream-changes would not apply.
What do you think of this? Do you have suggestions to improve this
workflow?
Ideally, if desired, dpkg-source --record-changes could be automatically
called in the build process but I'm wary of introducing something
interactive in the package build process.
Cheers,
[1] http://lintian.debian.org/tags/format-3.0-but-debian-changes-patch.html
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: