Bug 399019 – move unpack_{pdv,makeself} and friends to an eclass

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Christoph Junghans (RETIRED) 2012-01-15 19:04:03 UTC]

+++ This bug was initially created as a clone of Bug #384147 +++

(In reply to comment #13)
> i'd rather create an unpacker.eclass, move unpack_{pdv,makeself} there, and
> then add a default src_unpack() that handles all these various things

[Comment 1 SpanKY 2012-01-15 23:32:29 UTC]

Created attachment 299045 [details]
unpacker.eclass

[Comment 2 Christoph Junghans (RETIRED) 2012-01-16 00:51:49 UTC]

Looks great. 

Suggestions:
- general
 - global variable ${UNPACKER_TAR:=tar}, so that bsdtar could be used
 - merge-in rpm support
 - global array UNPACKER_FILELIST and give it to tar

- _unpacker
  - still missing: rar, 7z, tbz, tgz

- unpacker_src_uri_depends
 - transform names to lower cases
 - [[ $# -eq 0 ]] && set -- $SRC_URI

[Comment 3 SpanKY 2012-02-01 20:03:52 UTC]

(In reply to comment #2)

i don't see the point of allowing bsdtar.  portage doesn't either.

rpm and partial unpack list can come later.  i'll note them as todos.

i don't see the point of handling rar/7z when that is already in EAPI=0.  the point here is *not* to re-implement all of unpack().

[Comment 4 Christoph Junghans (RETIRED) 2012-02-01 20:54:37 UTC]

(In reply to comment #3)
> (In reply to comment #2)
> i don't see the point of handling rar/7z when that is already in EAPI=0.  the
> point here is *not* to re-implement all of unpack().
The problem with unpack() is, that it is defined in PMS, which makes it inflexible (e.g. adding lzma support for deb packages, bug #384147). Hence I would vote for making unpacker.eclass a replacement for unpack, which makes it cross-PM automatically.

[Comment 5 SpanKY 2012-02-02 00:41:14 UTC]

it makes no sense to duplicate code that works perfectly fine since EAPI=0

[Comment 6 SpanKY 2012-02-16 00:03:17 UTC]

we have unpacker.eclass now and eutils.eclass no longer carries these unpack_*