Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: polynomial-c@g.o
Subject: Re: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only
Date: Thu, 20 Feb 2014 16:40:07
Message-Id: 20140220173939.547559b4@pomiot.lan
In Reply to: [gentoo-dev] upstreams that release lzip compressed tarballs (tar.lz) only by Lars Wendler
1 Dnia 2014-02-20, o godz. 14:12:17
2 Lars Wendler <polynomial-c@g.o> napisał(a):
3
4 > So what can we do? Three solutions came to my mind which I list
5 > here in the order first being my favorite, last being my least
6 > favorite:
7 >
8 > 1.)
9 > Make portage's unpack function lzip compatible
10
11 Three packages still don't sound like something to add to EAPI. Even
12 with ten, I would have my doubts. Reading the whole thread, lzip
13 doesn't seem like it's going to live long. Trying to artificially force
14 it upon people is only going to give opposite results.
15
16 > 2.)
17 > Fix this on ebuild level:
18 > - add app-arch/lzip to DEPEND
19 > - add something like
20 > 'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die'
21 > to a custom src_unpack() function.
22
23 Either that, or add it to unpacker.eclass and use it. That's the place
24 where we handle all the random cruft, and where we can fix it as
25 problems arise.
26
27 > 3.)
28 > Provide all affected source tarballs ourselves in a portage compatible
29 > compressed format.
30
31 I think that'd be a waste of effort, to be honest. I think using lzip
32 (and lzip only) is the problem, and we shouldn't bury it like this.
33
34 > 4.)
35 > Try very hard to convince upstream to provide sources in differently
36 > compressed tarballs.
37
38 If you can't convince them yourself, let our users do that. Gentoo is
39 pretty specific in the way people handle extra dependencies they find
40 unnecessary :).
41
42 --
43 Best regards,
44 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies