[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Support of new source packages in squeeze


since I'm working on svn-buildpackage which aims at a similar target I'm
open for suggestions, so I pick some of your ideas up...

On Sun, Mar 08, 2009 at 11:55:11AM +1000, James Westby wrote:
>   * 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.

And how do you store that in a VCS if a second tarball includes files
that actually overwrite files of the main orig tarball. At build time
directories in the main orig tarball are supposed to be overwritten by
the part tarball but if you go the same way in a VCS you lose some
information, don't you?

>   * 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.

...which is difficult since /u/s/doc/dpkg-dev/README.api says that the
perl modules are not stable and only to be used in dpkg internally.
Some news on this? Having those modules available would be great!

>     - 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 don't think dak should reject such an upload but maybe I'm missing
something here. It still is an interesting question.

Maybe someone with a little more insight can jump in here with some
answers? :)


Attachment: signature.asc
Description: Digital signature

Reply to: