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: ryandes...@… | Owner: macports-
tick...@…
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?
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
