On Thu, 20 Feb 2014 16:28:30 +0100 Ulrich Mueller wrote: >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?
You can find some of his arguments in https://bugs.gentoo.org/249059 >> 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 Well, 4 is the most uphill of all solutions with little chance of success. And even if we can convince some upstreams, we'd still have to deal with the ones refusing our request. 3 is similar annoying as we have to make sure to provide these tarballs like forever. -- Lars Wendler Gentoo package maintainer GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC
signature.asc
Description: PGP signature
