1 |
>>>>> On Thu, 20 Feb 2014, Lars Wendler wrote: |
2 |
|
3 |
> it seems like some GNU projects start to release their source |
4 |
> tarballs in lzip compressed versions only [1][2]. This is a problem |
5 |
> since portage's unpack function doesn't know anything about lzip. |
6 |
> For sys-fs/ddrescue (where I am the Gentoo package maintainer) I |
7 |
> simply added "app-arch/lzip" to DEPEND and added an appropriate |
8 |
> src_unpack() function to the ebuild. That immediately lead to [3] |
9 |
> where I got the request to get rid of that dependency by either |
10 |
> convince upstream to release their tarballs in a differently |
11 |
> compressed format or provide a recompressed source tarball myself. |
12 |
> My conversation with ddrescue upstream was not successful in the way |
13 |
> that they were willing to provide their sources in several |
14 |
> differently compressed tarballs. |
15 |
|
16 |
> Now sys-apps/ed started the same with version 1.10 [2] and I really |
17 |
> don't want to repeat the whole stuff from ddrescue again without |
18 |
> having this discussed here. |
19 |
|
20 |
All this trouble is due to the author of lzip, Antonio Diaz Diaz, who |
21 |
is trying to promote his own exotic format. Nobody else seems to use |
22 |
it. |
23 |
|
24 |
Last time I checked, lzip compressed slightly worse and was slower |
25 |
than xz-utils, so there really is no reason why one would want to use |
26 |
it. Maybe more important, even if lzip was at par with xz-utils, the |
27 |
latter has won the competition and is vastly more popular. |
28 |
|
29 |
What was his argument for refusing a release in .tar.xz format? |
30 |
|
31 |
> So what can we do? Three solutions came to my mind which I list here |
32 |
> in the order first being my favorite, last being my least favorite: |
33 |
|
34 |
> 1.) Make portage's unpack function lzip compatible |
35 |
|
36 |
> 2.) Fix this on ebuild level: - add app-arch/lzip to DEPEND - add |
37 |
> something like 'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die' to a |
38 |
> custom src_unpack() function. |
39 |
|
40 |
> 3.) Provide all affected source tarballs ourselves in a portage |
41 |
> compatible compressed format. |
42 |
|
43 |
> 4.) Try very hard to convince upstream to provide sources in |
44 |
> differently compressed tarballs. |
45 |
|
46 |
It would rate them in order 4, 3, 2, 1, with 4 being my favourite. |
47 |
|
48 |
Ulrich |