Bug#610298: phasing out tar-in-tar in source packages

[Luk Claes <luk@debian.org>]

On 01/17/2011 11:49 AM, Stefano Zacchiroli wrote:

> tar-in-tar source packages, i.e. Debian source packages which contains upstream
> sources in compressed form and uncompress them on the fly during the build
> process, are a bit of a PITA. They are particularly so for tools who want to do
> source code analyses on the code shipped by debian (e.g. the recently started
> DACA project) but, more generally, violate a good faith assumption that
> "apt-get source" will deliver an unpacked source package where the user can
> grep through upstream source code.

I still remember that I implemented kind of a hack to make debdiff work
with them :-)

I don't think tar-in-tar source packages are the main obstacle to make
the assumption that apt-get source will deliver a clean separation
between upstream and 'local' changes. But I do agree that *if* 3.0
source packages are 'a should' then tar-in-tar should not be used anymore.

> I haven't conducted an analyses of the amount of tar-in-tar source packages in
> the Debian archive (sorry about that), but per folklore it seems that there are
> very few such packages remaining in the archive. I guess this is so because
> tar-in-tar was mostly used to circumvent the lack of support for non-gzip
> compression in source packages, feature which is now provided by 3.0 source
> formats.

There are a couple of reasons for tar-in-tar source packages that I
remember coming across: multiple upstream sources combined as one Debian
source package, upstream does not provide gzip compressed tarball,
upstream contains debian directory. All of these can be easily 'solved'
by using 3.0 source formats and only by using these AFAICS.

I'm quite indifferent on whether we should try to phase out these
packages, though I do think that making 3.0 source formats 'a should'
should be a precondition to not introduce possible inconsistencies.

Cheers

Luk