Too many outright errors. Please. On Wed, Apr 4, 2012 at 17:01, Jan Stary <[email protected]> wrote:
> "/opt/local was chosen so as to avoid stomping on other various > installations" > > What "other various installations", exactly? > Any software not part of a package system such as Apple's own, Fink, MacPorts, Homebrew, etc. A highly incomplete ist of specific examples: - Growl extensions (specifically growlnotify installs there) - The official Haskell Platform installer - The official TeXLive installer It's the usual Unixy place for third party software, a point you yourself made at some point; how is it you are now unaware of it? > Nobody uses more then one port system on a given machine > Excuse me? Conflicts between the various installer systems happen fairly often, because people *do* try to use multiple installer systems --- as well as third party software independent of them (as above). > "/usr/local is not a viable choice because some software (especially auto* tools from Gnu) look in /usr/local > as a default location, which means MacPorts can't be > easily isolated when needed." > > I want to kindly ask the person who wrote this to elaborate, > and be as specific as can be: what exactly does it mean for macports > to be "isolated", and how exactly does e.g. auto* looking into > /usr/local stand in the way of it? > So, are you at all familiar with the concept of "repeatable builds"? It is something which has particular importance in the world of packaging systems: it means, among other things, that you can ensure that a package builds the same way and runs the same way on as many systems as possible. MacPorts would not be particularly useful if a port only built properly on its maintainer's machine. Isolation of the package system is part of what makes this possible. "/usr/local is not a viable choice because it is usually reserved > for the given system's admin to install items local to that system, > and tends to be a bad choice to have taken over by a non-system port > system". > > Yes, /usr/local i traditionaly used to install items local to that system. > How does it make it a bad choice for the macports prefix? > The stuff I install from macports IS local to that system! > By that same argument, installing anything via apt-get or yum on Linux should install to /usr/local because you're only installing it locally. You are misunderstanding the point here completely. /usr/local is specifically intended to be left alone by *any* package system. This includes MacPorts. > > This means incorrect libraries and headers > > that magically find their way in there via other installers > > will be used instead of the software that was actually intended. > > Whoa, stop right there. This paragraph makes no argument against > /usr/local, > it's just dissing it with meanlessly negative adjectives. > If you still believe this, reread my previous statements until you understand them. > The definition of /usr/local is a directory where users put things > > they've compiled themselves; things that did not come from the OS vendor. > > EXACTLY - such as the macports stuff! That's what I have compiled myself > (with the help of a Portfile); that's what did not come from the OS vendor. > See? > You have lost track of MacPorts being a package system. If you built it yourself, not as part of a package system, that's what /usr/local is for. No package system should be touching /usr/local. Again, this is just bad-mouthing. Why would anything under /usr/local > (or anything outside of macports) BE a problem, solely on the grounds > it is under /usr/local? Really? What "rogue software"? > ...and the fact that you keep repeating this indicates to me that you are not at all experienced in the concept of packaging, or package systems. You know about your own machine, you only care about your own machine; this is fine for you, but you fail to understand that the restrictions MacPorts operates under ensure that it will work on your machine instead of just the port maintainer's machine. Ironically, making the changes you claim are the only way that makes sense would probably result in MacPorts being unusable for you. (I am, by the way, seriously considering saving your message as a near perfect example of why developers so often produce code that works on their development machines but not in production.) -- brandon s allbery [email protected] wandering unix systems administrator (available) (412) 475-9364 vm/sms
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
