Re: Support of new source packages in squeeze
On Sun, 08 Mar 2009, James Westby wrote:
> * Building a 3.0 (native) package worked fine.
> * Building a 3.0 (quilt) package worked ok. There are two things that
> will need work here though:
> - If there are more tarballs required than .orig.tar.gz and
> .debian.tar.gz then it will not work. How do you specify what
> other tarballs are needed. I believe all bzr-builddeb needs to
> do here is to make sure they are available, which it currently
> only does for .orig.tar.gz.
There's nothing to specify here, dpkg-source uses all additional tarballs
that match the regexp (exactly like it identifies the .orig tarball
currently).
> * Importing a 3.0 (quilt) package fails.
> - It currently assumes too much about what parts make up a source
> package. At the very least this can be conditionalised on the
> "Format:", however it would be nice to rely on dpkg-dev for all
> of this.
What does it assume and what would you need ?
> - The new format doesn't behave the same when unpacked with
> "dpkg-source -su -x". When importing a source package it imports
> it in two parts, firstly the upstream part on to the "upstream"
> branch, and then the full unpacked source package on to the main
> branch, merging in the upstream part. Without a .orig made
> available this can't be done. I would be interested in how you
> believe this could work given a 3.0 (quilt) package made up of
> many tarballs. Perhaps "-su" should leave a .orig, and then
> ".<part>" for each ".<part>.tar.gz".
In theory you can use "dpkg-source --skip-patches -x" and import
everything except the debian dir. Those are the upstream sources, I'm not
sure it's interesting to handle each upstream tarball separately. In fact,
doing so could lead to conflicts since the additional tarballs might
replace a directory that is also in the main tarball.
In practice, there's one exception, the debian tarball can contain
binary files that are installed outside of the debian dir. Those are
necessary listed in debian/source/include_binaries.
So maybe we should add a new option that skips the extraction of the
debian tarball.
In any case, I don't see how -su can be of any help (given its
definition) and the -su option is specific to the old format. If we really
want to have a common option that works for all formats, we might
want to create a new option "--skip-debianization" or similar.
> * I don't even need to test, but it will be FAIL all over for doing
> anything with .orig.tar.bz2 currently. Most of this will just be
> removing assumptions about the name of the file, but some things
> are tougher questions that will affect things like dak too, for
> instance:
> - If I upload a package foo, version 1.0-1, with
> foo_1.0.orig.tar.gz, what should happen if I try and upload 1.0-2
> with foo_1.0.orig.tar.bz2? I presume from dak's point of view this
> will be rejected, but this means that bzr-builddeb kind of needs
> to know what 1.0-1 was uploaded with, to avoid it building a
> source package that won't be accepted. It's much the same problem
> as making sure you get exactly the same foo_1.0.orig.tar.gz, but
> it adds way in which it can fail.
AFAIK this should not be a problem in dak. The only thing that is
important is that once a file is installed in the repository, it
must stay the same over time (i.e. the content of any file must not
evolve). Dak ensures that by verifying that MD5/SHA1 stays the same
on all subsequent uploads.
> I would like to see the 3.0 formats in widespread use, so I'm keen to
> work on fixing these things.
Glad to hear that.
Cheers,
--
Raphaël Hertzog
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
Reply to: