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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110529085303.ga17...@rivendell.home.ouaza.com
