Bug 197750
| Summary: | archivers/unzip: INSTALL_AS_INFOUNZIP confuses users and breaks dependent ports | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dmitry Marakasov <amdmi3> | ||||
| Component: | Individual Port(s) | Assignee: | Emanuel Haupt <ehaupt> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | Flags: | bugzilla:
maintainer-feedback?
(ehaupt) |
||||
| Priority: | --- | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Auto-assigned to maintainer ehaupt@FreeBSD.org I fully agree with your reasoning. I've removed the option based on your patch. Thanks! A commit references this bug: Author: ehaupt Date: Sat Feb 21 08:46:48 UTC 2015 New revision: 379492 URL: https://svnweb.freebsd.org/changeset/ports/379492 Log: Remove the historic option INSTALL_AS_INFOUNZIP which would install the unzip binary as info-unzip instead of unzip. Setting this options breaks ports such as java/openjdk7. This could be fixed but the submitter an I don't see a good reason why to keep this option. PR: 197750 Submitted by: amdmi3 Changes: head/archivers/unzip/Makefile |
Created attachment 153092 [details] Patch I've been investigating openjdk7 build failure for some user, and discovered that he had INSTALL_AS_INFOUNZIP in his make.conf. Obviously, it made unzip port not install bin/unzip binary, which broke dependent ports that need unzip. Now I wonder, what is the purpose of that knob? I see no reason for optional installation of infounzip binary, so it may be installed unconditionally as a link to unzip (or vice versa). If the point is in optional installation of unzip binary, it requires cooperation from ports framework, namely Uses/zip.mk or bsd.commands.mk, which should tweak unzip dependency. The way INSTALL_AS_INFOUNZIP is implemented now is broken and if there's no real reason behind it, I propose to remove it. Patch attached.