>>>>> On Thu, 20 Feb 2014, Lars Wendler wrote: > it seems like some GNU projects start to release their source > tarballs in lzip compressed versions only [1][2]. This is a problem > since portage's unpack function doesn't know anything about lzip. > For sys-fs/ddrescue (where I am the Gentoo package maintainer) I > simply added "app-arch/lzip" to DEPEND and added an appropriate > src_unpack() function to the ebuild. That immediately lead to [3] > where I got the request to get rid of that dependency by either > convince upstream to release their tarballs in a differently > compressed format or provide a recompressed source tarball myself. > My conversation with ddrescue upstream was not successful in the way > that they were willing to provide their sources in several > differently compressed tarballs.
> Now sys-apps/ed started the same with version 1.10 [2] and I really
> don't want to repeat the whole stuff from ddrescue again without
> having this discussed here.
All this trouble is due to the author of lzip, Antonio Diaz Diaz, who
is trying to promote his own exotic format. Nobody else seems to use
it.
Last time I checked, lzip compressed slightly worse and was slower
than xz-utils, so there really is no reason why one would want to use
it. Maybe more important, even if lzip was at par with xz-utils, the
latter has won the competition and is vastly more popular.
What was his argument for refusing a release in .tar.xz format?
> So what can we do? Three solutions came to my mind which I list here
> in the order first being my favorite, last being my least favorite:
> 1.) Make portage's unpack function lzip compatible
> 2.) Fix this on ebuild level: - add app-arch/lzip to DEPEND - add
> something like 'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die' to a
> custom src_unpack() function.
> 3.) Provide all affected source tarballs ourselves in a portage
> compatible compressed format.
> 4.) Try very hard to convince upstream to provide sources in
> differently compressed tarballs.
It would rate them in order 4, 3, 2, 1, with 4 being my favourite.
Ulrich
pgpYIcEnBsSTN.pgp
Description: PGP signature
