As per title, I have a system that didn't have unzip on it. I tried to emerge Myth and it complained. Reproducible: Always Steps to Reproduce: 1. emerge -C unzip 2. emerge mythtv 3. Actual Results: failed to emerge None required
This is really a bug with the package managers. If they claim they support unzip, they're the ones in fact depending on unzip. I've had this discussion several times with the Portage guys.
*** Bug 283072 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > This is really a bug with the package managers. If they claim they support > unzip, they're the ones in fact depending on unzip. > > I've had this discussion several times with the Portage guys. > It does seem it's their end, however, shouldn't we depend on it until they fix it on their side?
I've added it temporarily to the eclass until this is fixed correctly.
It's not realistic to have package managers depend upon every possible extracting tool they could use, since that would include several highly obscure tools used only by a very small number of packages. Forcing every user to have things like 7zip installed is silly. There are proposals for switching to a dependency like special/unpack-zip in future EAPIs to avoid hard-coding the unpacker, but that's a separate issue. Closing this off as fixed, anyway, since the package correctly sets the dep, as policy says it should.
You're 100% correct that the packager shouldn't depend on every single different compression algo software. However, it should take action to add to the DEPEND the unpackager its going to use based on SRC_URI as I've been saying for a while. Having the package depend on the unpackager is incorrect because the ebuild maintainer has NO IDEA if Paludis is going to use foo or bar to unpack zip's. Portage might use baz and then we're in a complete world of hurt.
It can't go off SRC_URI. That gives false positives. And no, PMS specifies which program is used to do the unpacking. That's the point -- package managers *have* to use a particular program, so that ebuilds can get the dependency right.
(In reply to comment #6) > You're 100% correct that the packager shouldn't depend on every single > different compression algo software. However, it should take action to add to > the DEPEND the unpackager its going to use based on SRC_URI as I've been saying > for a while. > As ciaramn said you can't rely on SRC_URI as it's possible that the ebuild never unpack the declared zip file. The current policy is to a add a DEPEND when you are unpacking something that's not provided by the default system target.
Looks like this has been fixed long time ago.
