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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
