>>> Unpacking source... >>> Unpacking mythplugins-0.21_p20323.zip to /var/tmp/portage/www-apps/mythweb-0.21_p20323/work /usr/lib64/portage/bin/ebuild.sh: line 380: unzip: command not found * * ERROR: www-apps/mythweb-0.21_p20323 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 3291: Called _eapi0_src_unpack * ebuild.sh, line 593: Called unpack 'mythplugins-0.21_p20323.zip' * ebuild.sh, line 380: Called die * The specific snippet of code: * unzip -qo "${srcdir}${x}" || die "$myfail" * The die message: * failure unpacking mythplugins-0.21_p20323.zip * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/www-apps/mythweb-0.21_p20323/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/www-apps/mythweb-0.21_p20323/temp/environment'. Reproducible: Always Steps to Reproduce: emerge a fresh system without installing unzip (7z may be installed, but this script does not use it's zip support) Actual Results: All required non-core/system tools should be marked as dependencies. 7z may be considered for use instead. emerging unzip manually should work around this issue.
Adding app-arch/unzip as a build time dependency would resolve the issue here.
This is the issue that I highlighted a while back with the Portage team. Basically, the package manager supports and uses different un-compression programs (i.e. gzip, bzip2, zip, lzma). It needs to somehow inject the uncompression tool into the DEPEND for that package. OR We need to make it a rule that every ebuild requires the maintainer to add the proper DEPEND for the uncompression tool used by EVERY package manager because Paludis may use 7z to uncompress zip's while Portage uses unzip (I know Paludis doesn't do this... I'm just using it as an example). Then the ebuild maintainer would have to add a depend on both unzip and 7z. This really needs to be clarified in the PMS.
PMS has this already -- it forces the package manager to use a particular program to do the unpacking, and requires ebuild authors to depend upon that program themselves. It's icky, but it's already there, and IIRC repoman used to check it. There's been discussion about a nice solution for this for EAPI 4, but I doubt it'll go anywhere until EAPI 3's out of the way and we can start thinking about the future.
Thanks Ciaran. Let's keep this on the plate for EAPI 4 and I'll happily contribute to the resolution. I dunno how you want to handle this bug... I've fixed the package in question.
I'll close this one off. The issue's already on the big long list somewhere.
