#18602 closed defect (fixed)
Prevent MacPorts from being configured with --prefix=/usr/local
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 1.8.0 |
Component: | base | Version: | 1.7.0 |
Keywords: | Cc: | macports@… | |
Port: |
Description
MacPorts should not allow users to configure it with --prefix=/usr/local
. Doing so surely breaks some ports, such as macfuse.
Change History (6)
comment:1 Changed 15 years ago by blb@…
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 14 years ago by macports@…
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Surely breaks some ports? Funny, haven't noticed that. But I have noticed the changeset associated with this ticket surely breaks my macports installation.
Please, don't be a nanny to the users. Document a potential issue with a port, or patch the port to fix it, but don't break the macports installation for everyone that installed into /usr/local and is now faced with a COMPLETE reinstall or manually undoing your broken 'patch' on every update.
comment:3 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | macports@… added |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
We do not have the resources to support every user's whim, and the whim of setting the MacPorts prefix to /usr/local is one that is fraught with peril and a high degree of probability that users will encounter unique problems that they will then write to us for help with that we will then waste time dealing with. We don't want to waste time on that, so we disabled this ability. If you have comments about this decision, please write to macports-users; do not re-open tickets fixed 15 months ago.
comment:4 Changed 14 years ago by macports@…
Resolution: | fixed |
---|---|
Status: | closed → reopened |
You mean broken 15 months ago!
Seriously, blocking a viable and used option is pretty damn retarded when you could print a warning during the configure process if you are that concerned. By your logic, you should add /System, /Library, /System/Library, /var, /usr, /bin, /sbin, /etc, /usr/bin, and a whole host of others to the blocklist because I just might decide to get crazy and shoot myself in the foot by setting any of those for the prefix. Better yet, just remove --prefix and hardcode it to install into /opt/local/macports/is/da/friggin/bomb/bitches and then you know it can't conflict with anything! I'm sure the users would love not having a choice because choices are hard, durrrr.
P.S. You've wasted my time by making me backout this patch every time I update so I have no problem wasting your time by reopening a ticket to let you know how hard you suck.
comment:5 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Unfortunately a lot of users don't really know what they're doing, and will try to do things that are prone to cause problems. We believed setting the MacPorts prefix to /usr/local was one of those things, so we blocked it.
If you believe /usr/local is a viable prefix for MacPorts you should discuss this on the macports-users mailing list. (A ticket is not a good place to have a discussion.) I don't remember all the reasons why we decided to block /usr/local, but if you've been using MacPorts in /usr/local successfully for 15 months without problems that's good to know, and it would be interesting to hear (on the mailing list) how many and what kinds of ports you've been installing.
comment:6 Changed 14 years ago by jmroot (Joshua Root)
The reasons why we don't default to installing in /usr/local are covered in the FAQ. I don't recall any reason being given for disabling it entirely beyond it breaking macfuse. I pointed out to blb at the time that there might be users with a legitimate reason to use it, and he responded that we could relax the restriction if anyone complained, by adding a --i-understand-that-usr-local-is-unsupported configure option or whatever. So, now someone has complained (for the first time as far as I'm aware).
Done in r53728.