Hi, Raphael Hertzog <hertzog@debian.org> (29/05/2011): > 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. thanks for trying to improve the situation. > 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? I think that from 1.0 format, a use case is still broken with that approach: - build a package - install its binaries - check the behaviour is the same as with the package in the archive (i.e. rebuilding doesn't fix the issue magically) - hack hack hack - debuild|dpkg-buildpackage -b -nc → oh, files were patched/unpatched/changed, you get to rebuild a lot of things, instead of just the relevant files Unfortunately I come empty-handed, but I wanted to mention that use case anyway. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature