dpkg-source's future and relation with VCS
Hello,
I've been thinking a lot about dpkg-source and the source package format
following all the discussions (sourcev3, coping with patches sanely on
-devel, etc.).
We all know the limitations of the current source package format (1.0) but
I'll repeat them here anyway:
- it doesn't handle multiple upstream tarball (which results in people
using tarballs in tarball)
- it doesn't handle addition of binary files (people are forced to uuencode
icons in the debian directory)
- in many cases, the extracted sources do not correspond to the built
sources as debian patches are not auto-applied and there are several
different ways to apply them depending on the tool used
this is because the single diff is not a nice way to keep changes to
upstream code and people have been working around it to keep patches
separated as they ought to be
- it doesn't ignore VCS specific files by default (we have to pass -i -I
regularly to dpkg-source)
I believe the wig&pen format [1] solves most of those concerns. I believe
that with some minor changes, it would satisfy the need of most packages
(even those using complicated build system).
I'd like in particular to have an explicit list of patches to apply at
unpack time. That "series" file would probably embed the distribution name
so that derived distribution (e.g. Ubuntu) can simply add their own series
file and add some specific patches (branding) or disable some debian
specific changes.
But the complicated part comes when we try to think of interactions
between VCS and source package format. I'd like to keep the (default)
source package format mostly VCS agnostic but I'd like the source
package to be easily generated from a VCS. The idea is the following:
- dpkg-dev (or dpkg-dev-vcs) provides VCS-specific scripts in
/usr/share/dpkg-dev/ that can be used to generate a wig&pen source
package from a VCS repository
- the package's repository contains a debian/source.rules that provides a
target "build" to create the wig&pen source package, during the process
the debian/source.rules file is not copied over... so that someone
extracting the wig&pen source package and trying to rebuild the package
do not end up trying to build the package from a VCS when he doesn't
have any. That makes "debian/sources.rules" a repository specific file.
- note that debian/sources.rules could support a "build-v3" target that
would generate a $VCS.tar.gz as an alternative to the default wig&pen
format (in that case, it would make sense to include the source.rules
file in the source package however)
- also note that we can have several variants of the build scripts even
for a single VCS (think one using feature branches and one that doesn't)
- in any case, I suggest using the Build-Options: field discussed several
times already (#229357) to let the dpkg-source know that the package supports
the new source format (instead of using a dedicated field)
debian/source.rules would receive as input some variables (for example
the list of *.orig(?:-[^-]+)?.tar.gz that have been found for this
package) and would output some special lines to indicate which files
are part of the generated source package.
The source.rules could also have some special rules like "import-changes"
that take a source package as input (say a NMU) and try to integrate the
changes in the local repository.
I plan to write code in that direction:
- clean up dpkg-source and move code in a Dpkg::Source API
- add the API required for wig&pen
- make dpkg-source be able to generate wig&pen source package
- then add some scripts that use the wig&pen API to generate source
packages from a VCS directory
Comments are welcome.
Cheers,
[1] http://www.dpkg.org/dpkg/NewSourceFormat
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: