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

Re: Support of new source packages in squeeze



On Sun, 2009-03-08 at 17:11 +0100, Raphael Hertzog wrote:
> There's nothing to specify here, dpkg-source uses all additional tarballs
> that match the regexp (exactly like it identifies the .orig tarball
> currently).

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.

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.

> What does it assume and what would you need ?

I'm not sure I would actually need anything more from dpkg-dev for this
at this point. I think it's just a case of updating the code.

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

Something will be needed for the use case I have, your proposed option
sounds sensible to me.

Thanks,

James


Reply to: