Re: Support of new source packages in squeeze

[James Westby <jw+debian@jameswestby.net>]

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 hertzog@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