I couldn't find a bug for this :-/ Currently, we need to manually DEPEND, for example, on app-arch/xz-utils when our distfiles use .xz. Would be nice if this DEPEND could be added automatically when needed instead of needing to add this DEPEND on a lot of ebuilds Thanks a lot Reproducible: Always
Alas, having a file extension in SRC_URI doesn't mean something will want to extract that using 'unpack'. I think there's a bug around somewhere for adding a magic/unpack-xz dep so you don't need to hard-code the package name, at least (and so package manglers can use other tools).
i believe you mean bug 399019
Then, should we simply use unpacker.eclass for xz? Looks like this problem is already handled by it :-/
Initial implementation of automatic unpack dependencies is now available in Portage: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=44f2b8f9603964abe230cfe8ef75831a82855da5 What syntax in SRC_URI should be used to specify that a file should not be unpacked and dependency on unpacker should not be automatically added? Maybe "-" after filename? Example: SRC_URI=" http://example.com/file1.gz http://example.com/file2.bz2 - http://example.com/file3_.xz -> file3.xz - doc? ( http://example.com/file4.zip - http://example.com/file5.lha ) examples? ( http://example.com/file6.rar - ) " In the above example, only "${unpacker_for_gz} doc? ( ${unpacker_for_lha} )" would be automatically added to DEPEND.
Is there a reason to keep this one open? I feel like we're not supposed to make PMS reliant on any specific package names.
(In reply to Michał Górny from comment #5) > Is there a reason to keep this one open? I feel like we're not supposed to > make PMS reliant on any specific package names. Closing.
