Hi, 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.
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.
What do you think?
[1] ftp://ftp.gnu.org/gnu/ddrescue/
[2] ftp://ftp.gnu.org/gnu/ed/
[3] https://bugs.gentoo.org/485462
--
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
