On Thu, 2009-03-05 at 22:19 +0100, Raphael Hertzog wrote:
> All in all, things are in a rather good shape but I still need some help.
> While I tested extensively the dpkg-source side, we still need to ensure
> that all our additional tools cope well with the new source package
> format (*-buildpackage, apt-get source, lintian, devscripts, dput/dupload,
> etc.). I know several tools in devscripts have already been fixed/enhanced
> in that regard. Please try using new source packages with all those tools
> (in particular if you maintain them) and file bugs if you encounter
> problems and usertag them appropriately (user hert...@debian.org /
> tag 3.0-quilt-by-default).
Hi,
I've just spent a bit of time trying to test bzr-builddeb with the new
formats, with mixed results.
* 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.
- Providing a more bzr-like way to handle debian/patches would be
nice, but that has always been the case.
* Importing a 3.0 (native) package worked fine.
* 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.
- 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".
* 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.
I would like to see the 3.0 formats in widespread use, so I'm keen to
work on fixing these things.
Thanks,
James
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
