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

[Vasudev Kamath]

Hi Jonas,

On 13:14 Tue 12 Feb     , Jonas Smedegaard wrote:
> 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: 
> http://copyninja.info/2013/02/new_series_of_posts_on_cdbs_packaging.html
> 
> We also hang out pretty regularly at #cdbs on the OFTC.net irc network, 
> in case others want to join us there.

Wow thanks for overwhelming welcome jonas :-)
> 
> 
> 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.

So I will only add an extension .tar.xz and leave repackaging things 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.

Interesting.

> 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 
> interested.
>

I'm not getting what you meant here. Did Jeremy Lal created a repackage
utility? Or he has plans to create one?


-- 
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4  C96B 6C8F 74AE 8770 0B7E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20130221/e8060a05/attachment.pgp>