[Build-common-hackers] Adding support for xz compression in upstream-tarball.mk

Jonas Smedegaard dr at jones.dk
Tue Feb 12 12:14:16 UTC 2013

Hi Vasudev,

First of all: welcome to the team!

To others here: Vasudev and I are collaborating on a few projects, 
including some packaging where I have introduced him to CDBS.  I am 
quite excited that he has chosen to get more involved.

Vasudev has started blogging about how to use CDBS: 

We also hang out pretty regularly at #cdbs on the OFTC.net irc network, 
in case others want to join us there.

Quoting Vasudev Kamath (2013-02-12 08:47:06)
> I filed a bug[1] yesterday requesting to add support for tar.xz 
> compression in upstream-tarball.mk.
> I was looking at fixing the issue myself and also fixed it by adding 
> tar.xz in below snippet
>         case "$(cdbs_upstream_received_tarball)" in \
>             *.tar.gz)  unpack="gunzip -c";; \
>             *.tar.bz2) unpack="bunzip2 -c"; grep -q '3.0 (quilt)' debian/source/format || uncompress="bunzip2";; \
>             *.tar.xz)  unpack="xz -dc";; \
>             *.tar.Z)   unpack="uncompress -c"; uncompress="uncompress";; \
>             *.zip)     unpack="unzip -q";      uncompress="false";       untar="-d"; nopipe="true";; \
>             *.tar)     unpack="cat";           uncompress="true";; \
>             *) echo "Unknown extension for upstream tarball $(cdbs_upstream_received_tarball)"; false;; \
> But I noticed that in case of repackaging the source upstream-tarball 
> blindly uses gzip compression. If upstream has provided source tarball 
> in xz compression wouldn't this be wrong thing to do? In general isn't 
> it nice to use the source tar in same file format as upstream gives 
> them?

Yes and no: Makes sense to extend to support more "output" formats than 
.tar.gz, and makes sense that target format by default is same as input 
- but only for formats actually supported in Debian.

Current code is not really elegant, and I fear it gets too messy to 
extend much further as-is.

Arguably the ideal CDBS-centric cleanup would be to properly express the 
various stages as make targets.

...but arguably the ideal Debian-centric approach would instead be to 
rewrite as self-contained tool, included with the devscripts package or 
maybe standalone and perhaps including a dh_repackage helper binary.

Another feature that might be interesting to include into such tool 
(pointed out to me by Jérémy Lal when he joined me in packaging 
BasiliskII) is that of ensuring that a repackaging is always identical.  
That should be possible by preserving/resetting timestamps, sorting 
order of content when seeded into tar, and possibly add some options 
like --rsyncable to the compression engine.  I never did succeed 
reproducing what Jérémy got working, so ask him for the details if 

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20130212/977d84c2/attachment.pgp>

More information about the Build-common-hackers mailing list