<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 14, 2014 at 12:56 PM, Gregory Shenaut <span dir="ltr">&lt;<a href="mailto:gkshenaut@ucdavis.edu" target="_blank">gkshenaut@ucdavis.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">I&#39;ve been reluctant to use anything under /opt because in the event I ever need to scrub macports and start over, it&#39;s easier to remove /opt and reinstall macports from scratch.<br>
</div></blockquote><div><br></div><div>Other third party software uses /opt as well (and even some Apple software; see xquartz). /opt/local is the only part that MacPorts touches; the rest of /opt is (and is there to be) fair game.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""></div>
It&#39;s a pity that macports isn&#39;t an official part of the system, like the freebsd ports are in fbsd, because if it were, then they (and not other ports) could simply install things right into the main system hierarchy. I believe that historically, really core elements of the OS went into /bin /lib </blockquote>
<div><br></div><div>This is a nightmare when installing newer versions of OS-provided things and when trying to keep base system and add-ons separate. Linux likes to pretend this is not a problem but its package managers are not really good enough to deliver on their claims; this often manifests as system upgrade failures.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">systems. As a result we have /opt /sw and so on (I have no idea why the original pattern of /usr/ucb wasn&#39;t followed with /usr/mp, /usr/fink, and so on, but it wasn&#39;t), as well as a host of </blockquote>
<div><br></div><div>/usr is often read-only on BSD-derived systems (while the relationship is now rather distant and I think OS X can&#39;t actually get away with r/o /usr, it is nevertheless BSD-derived and userspace is synced somewhat regularly with FreeBSD-CURRENT). /usr/ucb made sense in the original BSD context since it was populated as part of an OS install and could be considered read only afterward, plus you still had the original AT&amp;T versions of utilities available when needed for portability; &quot;aftermarket&quot; stuff doesn&#39;t really belong there (if you&#39;re remounting /usr r/w constantly to add software, you&#39;re doing read-only wrong)</div>
<div><br></div><div>/opt originated on Solaris, in part to support read-only (or shared; consider zones) /usr, but it seems like everyone else has come up with their own justification for it.</div><div><br></div></div>-- <br>
<div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</div></div>