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 |