On Thu, Feb 20, 2014 at 8:39 AM, Michał Górny <mgo...@gentoo.org> wrote:
> Dnia 2014-02-20, o godz. 14:12:17
> Lars Wendler <polynomia...@gentoo.org> napisał(a):
>
> > 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
>
> Three packages still don't sound like something to add to EAPI. Even
> with ten, I would have my doubts. Reading the whole thread, lzip
> doesn't seem like it's going to live long. Trying to artificially force
> it upon people is only going to give opposite results.
>
> > 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.
>
> Either that, or add it to unpacker.eclass and use it. That's the place
> where we handle all the random cruft, and where we can fix it as
> problems arise.
>
> > 3.)
> > Provide all affected source tarballs ourselves in a portage compatible
> > compressed format.
>
> I think that'd be a waste of effort, to be honest. I think using lzip
> (and lzip only) is the problem, and we shouldn't bury it like this.
>
>
I agree that this idea is a bad one, I recommend 2 or 4. 1 is obviously not
going to happen without more lzip adoption.
> > 4.)
> > Try very hard to convince upstream to provide sources in differently
> > compressed tarballs.
>
> If you can't convince them yourself, let our users do that. Gentoo is
> pretty specific in the way people handle extra dependencies they find
> unnecessary :).
>
> --
> Best regards,
> Michał Górny
>
