> 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?
Oh I am aware of it, and specifically mention it about two lines below the point where you cut my message, as you know. > > 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). Do you mean that someone uses, say, both macports and fink? > > "/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. Yes, I understand this. What I don't understand is how having /opt/local as a prefix makes this better than having /usr/local (or whatever else). > Isolation of the package system is part of what makes this possible. In what way exactly does having /opt/local make this possible as opposed to having /usr/local, which would not make it possible? (I'm not saying it doesn't; it's an honest question.) > "/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. This is exactly how OpenBSD's pkg_add works, for example: everything goes under /usr/local. I still don't see how that would be wrong here (besides a user himself stupidly rewriting things). > You are misunderstanding the point here completely. /usr/local is > specifically intended to be left alone by *any* package system. This > includes MacPorts. Where did you get this? This is what hier(7) says about /usr/local on my 10.5.8: executables, libraries, etc. not included by the basic operating system How does that exclude stuff from any package system? > > 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. Me doing './configure ; make ; make install' is a package system. (Not a very good one.) Does that prohibit me from /usr/local? No. Compiling something with macports (or fink or whatever) IS building it myself - except I didn't type the 'make' command with my fingers, it was read from a template. If I manually followed all the steps that macports does when building a package, would I be bulding it myself? As "opposed" to having it built by macports? > No package system should be touching /usr/local. Where did you get this? No really, where does this come from? > 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. That's right: I don't understand how having a default prefix of /opt/local (or /something/deffinitely/other/than/usr/local) ensures that. > Ironically, making the changes you > claim are the only way that makes sense would probably result in MacPorts > being unusable for you. Show me. If the default prefix changed to /usr/local, what exactly would break for me? (No irony here. I really want to know, and appreciate the time you spent answering my doubts.) _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users