Bug#554488: dpkg-dev: dpkg-source should support -su or -sn for 3.0 format packages

[Jaldhar H. Vyas]

Package: dpkg-dev
Version: 1.14.25
Severity: normal

libcgi-application-basic-plugin-bundle-perl is a package that aggregates
several Perl modules from CPAN (each of these is distributed upstream as
a .tar.gz)

What I currently do is to include these modules within in a
tarballs subdirectory of my package and unpack them at build time to
create the binary package.  This works but has all the disadvantages of
"tarballs in tarballs"

What I would like to do instead is to use the multiple .orig.tar.gz
feature of the 3.0 (quilt) source format.  Each module would become a
l-a-b-p-b-p_$version-$modulename-$moduleversion.orig.tar.gz and together
with my debian directory make up the source of my package.

The problem is dpkg-source seems to insist on there being a
l-a-b-p-b_$version.orig.tar.gz even though I have nothing to put in
there.  I can create an empty dummy one easy enough but this is an
unnecessary annoyance.

With a 1.0 format package I could use the -su switch to automatically
create the file from a l-a-b-p-b-p-$version.orig directory or even the
-sn switch to skip it altogether but this is not implemented for 3.0.  Is
there some reason why not?

--
Jaldhar H. Vyas <jaldhar@...>

-- System Information:
Debian Release: squeeze/sid
  APT prefers karmic-updates
  APT policy: (1100, 'karmic-updates'), (1100, 'karmic-security'), (1100, 'karmic-proposed'), (1100, 'karmic-backports'), (1100, 'karmic'), (99, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.31-14-generic-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg-dev depends on:
ii  binutils                2.20-0ubuntu2    The GNU assembler, linker and bina
ii  bzip2                   1.0.5-3          high-quality block-sorting file co
ii  dpkg                    1.15.4ubuntu2    Debian package management system
ii  libtimedate-perl        1.1600-9         Time and date functions for Perl
ii  lzma                    4.43-14ubuntu1   Compression method of 7z format in
ii  make                    3.81-6           An utility for Directing compilati
ii  patch                   2.5.9-5          Apply a diff file to an original
ii  perl [perl5]            5.10.0-24ubuntu4 Larry Wall's Practical Extraction
ii  perl-modules            5.10.0-24ubuntu4 Core Perl modules

Versions of packages dpkg-dev recommends:
ii  build-essential         11.4             Informational list of build-essent



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Wed, 04 Nov 2009, Jaldhar H. Vyas wrote:
> What I would like to do instead is to use the multiple .orig.tar.gz
> feature of the 3.0 (quilt) source format.  Each module would become a
> l-a-b-p-b-p_$version-$modulename-$moduleversion.orig.tar.gz and together

l-a-b-p-b-p_$version.orig-$module.tar.gz rather

> The problem is dpkg-source seems to insist on there being a
> l-a-b-p-b_$version.orig.tar.gz even though I have nothing to put in
> there.  I can create an empty dummy one easy enough but this is an
> unnecessary annoyance.
>
> With a 1.0 format package I could use the -su switch to automatically
> create the file from a l-a-b-p-b-p-$version.orig directory or even the
> -sn switch to skip it altogether but this is not implemented for 3.0.  Is
> there some reason why not?

-sn means "generate a native package" to me, I fail to see how that would
be relevant and helpful in your case. You don't want your package to be
native...

-su has not been kept because it really complicates the whole for no real
gain, you're the first one that I see using this option. Furthermore
creating the .orig.tar from a directory is not something that I want to
encourage/support since the tarball is not pristine any more in that case.

Ok, in your case there's no such pristine tarball but it's not really
more complicated to create the tarball than to create the empty directory.
You do it once, and then you just rename the previous .orig tarball.

What I can do however is add a supplementary option like
--create-empty-orig that would help bootstrap the process for your
specific case (that would not encourage repacking an upstream source
tree).

Cheers,
--
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jaldhar H. Vyas]

On Thu, 5 Nov 2009, Raphael Hertzog wrote:

> On Wed, 04 Nov 2009, Jaldhar H. Vyas wrote:
>> What I would like to do instead is to use the multiple .orig.tar.gz
>> feature of the 3.0 (quilt) source format.  Each module would become a
>> l-a-b-p-b-p_$version-$modulename-$moduleversion.orig.tar.gz and together
>
> l-a-b-p-b-p_$version.orig-$module.tar.gz rather
>

Actually what I did was to to change the .'s in the module version to -'s.
It works fine.


> -sn means "generate a native package" to me, I fail to see how that would
> be relevant and helpful in your case. You don't want your package to be
> native...
>

Well this combination of software doesn't exist outside of Debian but ok.

> Ok, in your case there's no such pristine tarball but it's not really
> more complicated to create the tarball than to create the empty directory.
> You do it once, and then you just rename the previous .orig tarball.
>

Right.  It's an annoyance not a show stopper.

> What I can do however is add a supplementary option like
> --create-empty-orig that would help bootstrap the process for your
> specific case (that would not encourage repacking an upstream source
> tree).

That would be wonderful.  Thanks!

--
Jaldhar H. Vyas <jaldhar@...>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Hommey]

On Thu, Nov 05, 2009 at 09:56:03AM +0100, Raphael Hertzog wrote:
> What I can do however is add a supplementary option like
> --create-empty-orig that would help bootstrap the process for your
> specific case (that would not encourage repacking an upstream source
> tree).

Why not simply allow not to have any .orig.tar.gz at all ? I mean, there
are other .orig.tar.gz files in his case, why insist on having an empty
package_version.orig.tar.gz ?

Mike



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Fri, 06 Nov 2009, Jaldhar H. Vyas wrote:

> On Thu, 5 Nov 2009, Raphael Hertzog wrote:
>
> >On Wed, 04 Nov 2009, Jaldhar H. Vyas wrote:
> >>What I would like to do instead is to use the multiple .orig.tar.gz
> >>feature of the 3.0 (quilt) source format.  Each module would become a
> >>l-a-b-p-b-p_$version-$modulename-$moduleversion.orig.tar.gz and together
> >
> >l-a-b-p-b-p_$version.orig-$module.tar.gz rather
> >
>
> Actually what I did was to to change the .'s in the module version
> to -'s. It works fine.

It works in sid but not yet in lenny, your package will be rejected at
upload because lenny's dpkg-source can't unpack it. See #554086.

And your template was still wrong, the supplementary tarballs are
.orig-<component>.tar.<ext> not -<component>.orig.tar.<ext>.

> >-sn means "generate a native package" to me, I fail to see how that would
> >be relevant and helpful in your case. You don't want your package to be
> >native...
> >
>
> Well this combination of software doesn't exist outside of Debian but ok.

But native means "a single tarball of everything", it just can't support
multiple tarballs.

> >What I can do however is add a supplementary option like
> >--create-empty-orig that would help bootstrap the process for your
> >specific case (that would not encourage repacking an upstream source
> >tree).
>
> That would be wonderful.  Thanks!

I changed the severity to wishlist due to this.

Cheers,
--
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Fri, 06 Nov 2009, Mike Hommey wrote:
> On Thu, Nov 05, 2009 at 09:56:03AM +0100, Raphael Hertzog wrote:
> > What I can do however is add a supplementary option like
> > --create-empty-orig that would help bootstrap the process for your
> > specific case (that would not encourage repacking an upstream source
> > tree).
>
> Why not simply allow not to have any .orig.tar.gz at all ? I mean, there
> are other .orig.tar.gz files in his case, why insist on having an empty
> package_version.orig.tar.gz ?

Because it's too late for such a design change IMO (and dak check for the
presence of the right files, etc).

I did not think of this case when I wrote the code, it was more intended
for stuff like have the main software in orig.tar and supplementary
tarballs for extra plugins, translations, but not for creating our own
collection of several upstream projects.

Cheers,
--
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Hommey]

On Fri, Nov 06, 2009 at 08:36:10AM +0100, Raphael Hertzog wrote:

> On Fri, 06 Nov 2009, Mike Hommey wrote:
> > On Thu, Nov 05, 2009 at 09:56:03AM +0100, Raphael Hertzog wrote:
> > > What I can do however is add a supplementary option like
> > > --create-empty-orig that would help bootstrap the process for your
> > > specific case (that would not encourage repacking an upstream source
> > > tree).
> >
> > Why not simply allow not to have any .orig.tar.gz at all ? I mean, there
> > are other .orig.tar.gz files in his case, why insist on having an empty
> > package_version.orig.tar.gz ?
>
> Because it's too late for such a design change IMO (and dak check for the
> presence of the right files, etc).

That pretty much depends on what dak is expecting to be the right files.
If it can handle the additional tarballs, doesn't it mean it properly
parses the .dsc and/or .changes files ? And that it could cope with no
tarball being package_version.orig.tar.gz ? (naive question)

Mike



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Fri, 06 Nov 2009, Mike Hommey wrote:
> That pretty much depends on what dak is expecting to be the right files.
> If it can handle the additional tarballs, doesn't it mean it properly
> parses the .dsc and/or .changes files ?

It does and verify that we have all the required files for the announced
source format.

> And that it could cope with no tarball being package_version.orig.tar.gz
> ? (naive question)

Right now it would complain exacly like dpkg-source does since I coded
both parts to match. :-)

Cheers,
--
Raphaël Hertzog



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...