[MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local

[Joshua Root]

Ryan Schmidt wrote:
> On Feb 22, 2009, at 22:10, Rainer Müller wrote:
> 
>>> #18602: Prevent MacPorts from being configured with --prefix=/usr/local
>>> -------------------------------------+--------------------------------------
>>>
>>>  Reporter:  ryandesign@…             |       Owner:  macports-tickets@…
>>>      Type:  defect                   |      Status:  new
>>>  Priority:  Normal                   |   Milestone:  MacPorts 1.8.0
>>> Component:  base                     |     Version:  1.7.0
>>>  Keywords:                           |        Port:
>>> -------------------------------------+--------------------------------------
>>>
>>>  MacPorts should not allow users to configure it with
>>>  `--prefix=/usr/local`. Doing so surely breaks some ports, such as
>>>  [comment:ticket:15778:3 macfuse].
>>
>> I don't think we should forbid it completely. Adding a warning and a
>> link to the appropriate FAQ entry should be enough.
> 
> 
> 
> The most compelling reason I can think of to forbid prefix from being
> /usr/local is that most software installs there by default when
> configured without specifying a prefix. This means it would be very easy
> for someone to overwrite something installed by MacPorts, or at least to
> install software into the MacPorts prefix, if they configured something
> by hand and forgot to (or did not know they should) specify a different
> prefix.
> 
> There are also binary packages that install into /usr/local. MySQL and
> Graphviz come to mind. Ok, the MySQL binary installs into
> /usr/local/mysql-${version} so it won't conflict with MacPorts software,
> but that's still under /usr/local. Graphviz installs to prefix
> /usr/local. I asked them not to do this but I was unable to dissuade them.

You couldn't dissuade them because /usr/local is in fact the correct
place to install non-vendor-supplied software that should be available
to all users of the machine. The issue for us is that it's hard to get
configure scripts to not look there.

I really don't think we should be trying to save users from themselves
to this extent. If they really want to shoot themselves in the foot,
that's their choice. We should, however, make it very clear that that is
what they are doing.

- Josh