> You keep saying that: "the software that magically finds its way to > /usr/local". What do you even mean by that? The user installed it > there; that's about the only way something gets into /usr/local.
The user is typically unaware of where packaged software is installed. You can look at our mounds of trouble tickets that were caused by this specific reason. The user simply ran some installer program, and magic happened. > And how do we stop the user from rewriting something that is already there? > We don't, and we can't. It's the user's responsibility to not be an idiot > and rewrite something he has installed himself before. That is a reason why we shouldn't use /usr/local: users are less to ran an installer that clobbers inside MacPorts-specific directories. > In fact, what difference does "/usr/local or /opt/local" > (or any ther prefix for that matter) make in this respect? > In the current state of things, how do you stop the user > from overwriting something that macports has installed under > /opt/local? There is a huge difference between: * the user explicitly running a command to overwrite MacPorts, and * the user ran an installer that did something somewhere. When the user runs an installer program, chances are it won't install to /opt/local but instead install to /usr/local or /Library. Since /usr/local is a prime target, it would be very likely that users routinely overwrite MacPorts on accident. > You don't, because you can't. It's the user's responsibility > to not install over something that is already installed > (whatever the prefix is). If only all OS X users could know what they were doing.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
