Summary: | move unpack_{pdv,makeself} and friends to an eclass | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christoph Junghans (RETIRED) <junghans> |
Component: | Eclasses | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | floppym, junghans, pacho |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | unpacker.eclass |
Description
Christoph Junghans (RETIRED)
2012-01-15 19:04:03 UTC
Created attachment 299045 [details]
unpacker.eclass
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 (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(). (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. it makes no sense to duplicate code that works perfectly fine since EAPI=0 we have unpacker.eclass now and eutils.eclass no longer carries these unpack_* |