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