1 |
Hi, |
2 |
|
3 |
it seems like some GNU projects start to release their source tarballs |
4 |
in lzip compressed versions only [1][2]. |
5 |
This is a problem since portage's unpack function doesn't know anything |
6 |
about lzip. |
7 |
For sys-fs/ddrescue (where I am the Gentoo package maintainer) I simply |
8 |
added "app-arch/lzip" to DEPEND and added an appropriate src_unpack() |
9 |
function to the ebuild. That immediately lead to [3] where I got the |
10 |
request to get rid of that dependency by either convince upstream to |
11 |
release their tarballs in a differently compressed format or provide a |
12 |
recompressed source tarball myself. My conversation with ddrescue |
13 |
upstream was not successful in the way that they were willing to |
14 |
provide their sources in several 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 having |
18 |
this discussed here. |
19 |
|
20 |
So what can we do? Three solutions came to my mind which I list |
21 |
here in the order first being my favorite, last being my least |
22 |
favorite: |
23 |
|
24 |
1.) |
25 |
Make portage's unpack function lzip compatible |
26 |
|
27 |
2.) |
28 |
Fix this on ebuild level: |
29 |
- add app-arch/lzip to DEPEND |
30 |
- add something like |
31 |
'tar --lzip -xf "${DISTDIR}"/${P}.tar.lz || die' |
32 |
to a custom src_unpack() function. |
33 |
|
34 |
3.) |
35 |
Provide all affected source tarballs ourselves in a portage compatible |
36 |
compressed format. |
37 |
|
38 |
4.) |
39 |
Try very hard to convince upstream to provide sources in differently |
40 |
compressed tarballs. |
41 |
|
42 |
|
43 |
What do you think? |
44 |
|
45 |
[1] ftp://ftp.gnu.org/gnu/ddrescue/ |
46 |
[2] ftp://ftp.gnu.org/gnu/ed/ |
47 |
[3] https://bugs.gentoo.org/485462 |
48 |
|
49 |
-- |
50 |
Lars Wendler |
51 |
Gentoo package maintainer |
52 |
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC |