Source package format - a simple proposal

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

While this discussion was going on, I posted a list of requirements
for our source format.  I think that there is a very simple way we can
support most of these requirements without many problems.  Firstly,
the requirements (summarised):

 1. Single file, unpacked using 1 command to make debianised src.
 2. Single file, unpacked using 1 command to make upstream src.
 3. Consistent naming schemes for unpack directories.
 4. Patches for different arch's [1].
 5. Can be manipulated on non-Debian systems using standard tools.
 6a. No unnecessary up/down-loading by maintainers.
 6b. No unnecessary disk space usage on archive sites.
 7. No execution of parts of source package when unpacking.
 8. Sensible way to rebuild source from unpacked tree(s).

I propose that the source package for `foo', version 1.2 revision 5,
would be a gzipped tarfile with the following structure:

  foo-1.2-5.debian-diff
  foo-1.2.orig/foo.c
              /foo.h
              &c

The directory foo-1.2.orig would contain the original source package's
files; the only changes would be to make the directory name consistent
(and to possibly to make the permissions in the source tree sensible
if they aren't in the upstream source).

We can easily provide a script (the dpkg package would be the right
place for it) that turns this into
   foo-1.2/debian.*
          /foo.c
          &c
   foo-1.2.orig/foo.c
               &c
and another that turns that back into a source package without
disturbing the directories.

For a source package that comes as more than one file (tarfile or
otherwise) we can provide a debian.* script in the debianised version
of the source that takes the files downloaded from the package's FTP
site and turns them into the directory structure in our source
package.

A user who gets the .tar.gz and just unpacks it will see the obvious
thing.  They can rename foo*.orig to foo* and apply the diff manually
if that's all they want to do.

This meets requirements 1, 2, 3, 5, 7, 8.

Maintainers who change only the control file or something still have
to upload a new source tree, unfortunately, but we can if we like
avoid this by having them submit only a new diff and reconstructing
the .tar.gz on the distribution site using a simple script.  That
supports 6a and 6b.

[1] The scheme is easily extended to support item 4 (per architecture
patches), but I still think this is a bad idea.

Ian.