[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg-source's future and relation with VCS


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.


[1] http://www.dpkg.org/dpkg/NewSourceFormat
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :

Reply to: