FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-05-2008, 04:51 PM
Bart Martens
 
Default tarball in tarball: opinions

On Sat, 2008-07-05 at 12:21 -0400, Jay Berkenbilt wrote:
> So, is using tarball in tarball considered "bad" these days?

I see no reason to consider this "bad".

> Is it
> viewed as an approach that once had its time but is now discouraged,
> or

I don't use it, but don't let that discourage you.

> is it just a matter of personal preference

Yes I think that it's a matter of personal preference / packaging style.

> and creating a
> README.source that tells the user what to do file makes it all okay?

It is a good idea to document tricky things in such a README file.

>
> I want my packages to be in the best possible shape, so I'm trying to
> decide whether I should go to the trouble of changing my personal
> packaging habits to work around the two issues above.

Trying something new is sometimes fun.

> Some of these
> will be easier to handle after we can switch to 3.0 (quilt), but as
> far as I know, there is no way to replace your .orig.tar.gz without
> changing the package version, and I don't want to introduce epochs for
> this.

No need to introduce epochs. You can update package foo-1.2.3-4 to
foo-1.2.3+debian-1 or something similar.

>
> Advice welcome.

My advice is that you use the packaging style conforming to
debian-policy that you feel most comfortable with.

Regards,

Bart Martens



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-05-2008, 06:17 PM
"Bernhard R. Link"
 
Default tarball in tarball: opinions

* Jay Berkenbilt <qjb@debian.org> [080705 18:22]:
> * I like to have an exact copy of the downloaded source tarball with
> the same md5 checksum, gpg detached signature, etc. Using the
> rules/tarball.mk from cdbs provides a very convenient way of
> handling this.

I consider this the main reason I personally consider tarball in tarball
bad: The .orig.tar.gz is totally different to the upstream tarball.
If upstream already has a .tar.gz then there is no excuse in my eyes
and even with .tar.bz2 it's easier to download this, check it, unpack
both and compare some checksums, than to first look into the file if it
is the same, then detecting it is not supposed to be the upstream file,
unpack it, look how the file is named in there and then comparing those.

Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-05-2008, 07:45 PM
Magnus Holmgren
 
Default tarball in tarball: opinions

On lördagen den 5 juli 2008, Jay Berkenbilt wrote:
> * I like to have an exact copy of the downloaded source tarball with
> the same md5 checksum, gpg detached signature, etc. Using the
> rules/tarball.mk from cdbs provides a very convenient way of
> handling this.

The .orig.tar.gz is supposed to be that exact copy. What prevents you from
letting it be that? (Besides upstream providing only a .tar.bz2 (but that
will be supported with the 3.0 format) or .zip.)

> * I manage my debian directories in subversion, and I use
> svn-buildpackage to build. I always use "mergeWithUpstream".
> Sometimes I want to do something more involved, so I just manually
> extract my .orig.tar.gz files. I can't do this without tarball in
> tarball if my packages either contain their own debian director
> that I don't use or if they extract to a directory other than
> pkg-version.

Upstream tarballs containing debian directories are the exception, and should
be discouraged, but with the 3.0 (quilt) format they will be ignored anyway.
Tarballs using the wrong top-level directory name is nothing that can't be
worked around. You can always use svn-buildpackage --svn-export.

--
Magnus Holmgren holmgren@debian.org
Debian Developer
 
Old 07-05-2008, 08:36 PM
Joey Hess
 
Default tarball in tarball: opinions

Magnus Holmgren wrote:
> Tarballs using the wrong top-level directory name is nothing that can't be
> worked around.

dpkg-source does not care what directory (if any) a .orig.tar.gz extracts
into. There's nothing "wrong" about an upstream tarball extracting into
"<package>" instead of "<package>-<version>".

--
see shy jo
 
Old 07-05-2008, 09:04 PM
Joey Hess
 
Default tarball in tarball: opinions

Jay Berkenbilt wrote:
> So, is using tarball in tarball considered "bad" these days? Is it
> viewed as an approach that once had its time but is now discouraged,
> or is it just a matter of personal preference and creating a
> README.source that tells the user what to do file makes it all okay?

I've always hated it, particularly because it throws out the ability to
unpack the entire archive automatically and run code analysis tools on
it. Also because it was how people worked around many problems with the old
source format for years, instead of fixing the format.

README.source is a bandaid on a three-inch slash across our collective ankle.

--
see shy jo
 
Old 07-05-2008, 10:45 PM
Ben Finney
 
Default tarball in tarball: opinions

Jay Berkenbilt <qjb@debian.org> writes:

> * I like to have an exact copy of the downloaded source tarball with
> the same md5 checksum, gpg detached signature, etc. Using the
> rules/tarball.mk from cdbs provides a very convenient way of
> handling this.

Have you considered the debian/rules 'get-orig-source' target as an
alternative way of achieving this? If done right, that would allow you
to do this kind of checking *and* still follow recommended practice of
using the upstream tarball as yours.

I'm envisaging the 'get-orig-source' could download the upstream
tarball and rename it, along with the checksum and signature files, do
any checks, and exit with an error status if they don't match. If
everything *does* match, the checksum etc. files are removed, leaving
the upstream tarball with the standard name.

--
“I have a large seashell collection, which I keep scattered on |
` the beaches all over the world. Maybe you've seen it.” —Steven |
_o__) Wright |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-06-2008, 10:11 AM
Raphael Hertzog
 
Default tarball in tarball: opinions

(some of the answers/facts have already been given, but I reply anyway to
also give my personal opinion)

On Sat, 05 Jul 2008, Jay Berkenbilt wrote:
> * I like to have an exact copy of the downloaded source tarball with
> the same md5 checksum, gpg detached signature, etc. Using the

That should be the orig.tar.gz/bz2 file indeed.

> * I manage my debian directories in subversion, and I use
> svn-buildpackage to build. I always use "mergeWithUpstream".
> Sometimes I want to do something more involved, so I just manually
> extract my .orig.tar.gz files.
> I can't do this without tarball in tarball if my packages either
> contain their own debian directories that I don't use

This is not a problem with the new source format.

> or if they extract to a directory other than pkg-version.

This has never been a problem, dpkg-source always handled this.
If the orig tarball contains a single directory, it's renamed as
pkg-version, if it contains multiple directories they are moved as-is
inside a new pkg-version directory.

> So, is using tarball in tarball considered "bad" these days? Is it
> viewed as an approach that once had its time but is now discouraged,
> or is it just a matter of personal preference and creating a
> README.source that tells the user what to do file makes it all okay?

I have always found tarball in tarball a big nuisance. They are rightfully
justified _only_ when the source package is composed of multiple source
packages (such as the glibc for example). But the new source format
also support multiple upstream tarballs.

For the other cases, they are often used to work around a messy upstream
build system that is not able to clean the build directory properly. It
would be far more productive to write a patch to fix the upstream build
system and submit it rather than work around the deficiencies.

> will be easier to handle after we can switch to 3.0 (quilt), but as
> far as I know, there is no way to replace your .orig.tar.gz without
> changing the package version, and I don't want to introduce epochs for
> this.

Creating a fake version "version.ds" or "version+ds" is often used for
those cases (I believe "ds" stands for "debian specific" or something like
that).

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-06-2008, 02:46 PM
Jay Berkenbilt
 
Default tarball in tarball: opinions

Thanks for all the input on tarball within tarball. I will stop using
that format for all my packages with the possible exception of ICU
which contains its own debian directory.

I was aware of the fact that dpkg-source handles the tarball nnot
extracting to package-version and have, in fact, advised others that
repackaging the orig.tar.gz to get around this is not necessary. One
of my own packages (psutils) is this way. My point wasn't that
dpkg-source doesn't handle it, but that it makes it somewhat less
convenient to manually extract the source over top of my
svn-controlled debian directories. I was not aware of
svn-buildpackage --svn-export, pointed out by Magnus Holmgren
<holmgren@debian.org>, and I think that will solve my problem quite
nicely and prevent me from writing my own script that duplicates the
logic in dpkg-source.

With regard to the ICU packages, which include their own debian
directory, I tried unsuccessfully two years ago to convince upstream
to drop this. There has been a recent change of leadership in the
project, and I have (prior to my sending out my message to
debian-devel), post a bug to their bug tracking system requesting that
they drop the debian directory. If they don't, I may regenerate the
orig.tar.gz as I do not, but instead of using a tarball within a
tarball, I'll just push everything down one level. Once the 3.0
(quilt) format becomes acceptable to use for regular packages in the
archive, this becomes a non-issue, and I can use the upstream source
download as the .orig.tar.gz file.

Thanks for all the input and tips.

--
Jay Berkenbilt <qjb@debian.org>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 12:15 AM
Ben Hutchings
 
Default tarball in tarball: opinions

On Sat, Jul 05, 2008 at 08:17:21PM +0200, Bernhard R. Link wrote:
> * Jay Berkenbilt <qjb@debian.org> [080705 18:22]:
> > * I like to have an exact copy of the downloaded source tarball with
> > the same md5 checksum, gpg detached signature, etc. Using the
> > rules/tarball.mk from cdbs provides a very convenient way of
> > handling this.
>
> I consider this the main reason I personally consider tarball in tarball
> bad: The .orig.tar.gz is totally different to the upstream tarball.
> If upstream already has a .tar.gz then there is no excuse in my eyes
> and even with .tar.bz2 it's easier to download this, check it, unpack
> both and compare some checksums, than to first look into the file if it
> is the same, then detecting it is not supposed to be the upstream file,
> unpack it, look how the file is named in there and then comparing those.

All the 3.0 formats allow bzip2 tarballs so that will no longer be a
reason to do this. 3.0 (quilt) also allows multiple upstream tarballs
which used to be a good reason for using tarball-in-tarball.

Ben.

--
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
 
Old 07-10-2008, 11:36 AM
Frank Küster
 
Default tarball in tarball: opinions

Joey Hess <joeyh@debian.org> wrote:

> Magnus Holmgren wrote:
>> Tarballs using the wrong top-level directory name is nothing that can't be
>> worked around.
>
> dpkg-source does not care what directory (if any) a .orig.tar.gz extracts
> into. There's nothing "wrong" about an upstream tarball extracting into
> "<package>" instead of "<package>-<version>".

Or into ., even.

Regards, Frank
--
Frank Küster
Debian Developer (teTeX/TeXLive)


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

Thread Tools




All times are GMT. The time now is 02:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org