Re: Support of new source packages in squeeze
James Westby <jw+debian@jameswestby.net> writes:
> bzr-builddeb will endeavour to provide the ".orig.tar.gz" for a format 1
> package, so that you can construct a source package from a bzr branch.
>
> This will be essentially impossible for 3.0 (quilt) packages that use
> multiple tarballs, as there is no information in the unpacked source
> package that tells you which tarballs are needed. This is a pretty
> serious problem in my eyes.
git-buildpackage with pristine-tar is going to have a similar problem.
For pristine-tar, the solution that comes to mind is a
debian/source/tarballs file that lists the names of all of the upstream
tarballs. All you need there are the tarball names to know what to
generate. Of course, it doesn't have to live there (and maybe shouldn't);
you could use a builder-specific configuration file instead.
If you're trying to recreate the tarball from a set of files, this doesn't
work as well, but that also has other problems (it doesn't give you a
reproducible tarball). I suspect that if you're storing enough additional
metadata to know how to generate a reproducible tarball, you'll have
metadata to know how to build it. For pristine-tar, for example, I'd put
each upstream tarball on a separate branch and merge them together, so
that pristine-tar has a branch tag to use for commit and checkout.
> Have you thought about how this will work with things such as uscan?
> Having some way to check for newer versions of all the tarballs that
> go together to make the source package would be important.
I suspect that for a lot of the check-only use cases for this, checking
only one of the tarballs will be sufficient. (OpenAFS, for example, comes
upstream in the form of a source tarball and a documentation tarball, but
they always have the same version, so uscan can just check one of them.)
If you want to support uscan --download, though, yes, that's another
matter.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: