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

Re: 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

Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :

Reply to: