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

[Ryan Schmidt]

On Feb 23, 2009, at 00:10, Joshua Root wrote:

> 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.

So then Graphviz will not be alone in having chosen this location for  
their binary installer, and any number of software packages' binary  
installers could thus cause harm to a user's MacPorts installation if  
they have used prefix /usr/local.

> The issue for us is that it's hard to get
> configure scripts to not look there.

Right, and if some ports were to try to implement measures to  
specifically ignore /usr/local, well then that could easily cause  
problems if the prefix were in fact /usr/local.


> 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.


There's an infinite number of other prefixes the user could choose  
that would work fine. Why allow the user to use this prefix which  
will quite probably cause them problems in the future? What benefit  
can be obtained from using MacPorts with prefix /usr/local that  
cannot be achieved with other prefixes?

For good measure, we should prevent installation with prefix / or / 
usr as well, and, why not, /sw.

I've worked in tech support, and from that standpoint, I'd like to do  
what we can to reduce our email support volume. Preventing user  
actions which have no discernible benefit but which have a strong  
possibility of detriment seems like a win to me.

If we went with a warning instead of preventing the use of these  
prefixes outright, when would it be printed? My concern is that there  
is already so much output produced by configure, make and make  
install that it's easy to overlook things.

To expand on what I said before, we have a policy of telling users  
not to install software manually into the MacPorts prefix. Yet you  
know users just can't stop installing software separately from  
MacPorts. It's bad enough when users install software manually in / 
usr/local when they're using MacPorts in another prefix, but at least  
then we can tell them "delete /usr/local". Allowing users to get into  
a situation where they are likely to mix these in the same prefix is  
even worse, because then the answer is "delete /usr/local and  
reinstall MacPorts and all your ports". And you know a user who  
encounters problems will not begin their email with "I installed  
MacPorts into /usr/local and then installed some other software  
package that installs into /usr/local". It'll be many messages later  
before that information is finally extracted. Which will be time that  
could have been better spent on other issues to which we do not  
already know solutions. This issue already has a solution, which is  
"don't use /usr/local as your prefix" so I support enforcing this  
solution.


On Panther, libpixman requires Xcode 1.5. On Tiger, cairo requires  
Xcode 2.4.1+. On Leopard, graphviz requires Xcode 3.1+. If a user  
were to try with earlier Xcode, they would get an error. Yes, we  
already state those are the minimum versions required by MacPorts,  
but users don't read that, and they assume Software Update will  
update Xcode for them, which it won't. So the portfiles enforce this  
requirement with an error message telling them exactly what's wrong,  
instead of letting them proceed anyway to inevitably fail. Ok, maybe  
that's not a great comparison, since using an earlier Xcode with  
these ports will 100% definitely prevent them from installing,  
whereas using prefix /usr/local will not 100% definitely cause the  
user problems. But still it's a much greater chance of badness than  
with most other prefixes. One could argue this makes preventing /usr/ 
local et al all the more important: if I did not have Xcode version  
checks in libpixman, cairo and graphviz, it would merely waste a  
little of the user's time now while their computer compiles until it  
encounters one of several now well-known errors, they would either  
look it up or ask the list and be told to upgrade Xcode and would be  
on their way. Whereas installing with prefix /usr/local is a time  
bomb waiting to explode later when the user has long forgotten a  
warning printed during MacPorts installation.


That's what I think about it anyway. I do go on, don't I?