On Tue, Jul 8, 2008 at 4:58 PM, Mike Meyer <[EMAIL PROTECTED]> wrote: > On Tue, 8 Jul 2008 16:01:28 -0400 > "Fredrich Maney" <[EMAIL PROTECTED]> wrote: > >> On Tue, Jul 8, 2008 at 11:29 AM, Mike Meyer <[EMAIL PROTECTED]> wrote: >> > On Tue, 08 Jul 2008 04:23:45 PDT "Richard L. Hamilton" <[EMAIL PROTECTED]> >> > wrote: >> >> [...] >> >> > The FOSS systems went from the model Solaris is still using, with >> > package-specific directory trees - to a flatter model, folding pretty >> > much all the applications into /usr (GNU/Linux) or their equivalent of >> > /opt (the various BSDs). And yes, that includes making /opt/X* >> > symlinks to /opt to keep older software happy. >> >> Which is a big part of the problem with Linux - putting optional (non >> vendor supplied) packages/binaries/libraries in the (vendor supplied) >> system repositories. It leads to all sorts of conflicts and forced >> upgrades. That is part of the reasoning behind /opt - if only we'd >> insisted on doing that consistently instead of trying to be "Linux >> compliant". > > Actually, those are three different questions: > > 1) Does non-vendor-supplied software go into /usr? > 2) Should non-vendor-supplied packages be denied a global <package> > directory? > 3) Does non-vendor-supplied software go into the vendor repository?
I would argue that #1 and #2 are simply special cases of #3. In Solaris, as with most commercial Unix flavors, /usr is the vendor repository (usr does stand for Unix System Repository after all), /opt has been around since at least Solaris 2.5.1 and it, or it's close cousin /usr/local, is also very common on other commercial Unix flavors. It is only in the free world (Linux) where you routinely get into problems with vendor supplied and non-vendor supplied packages installing on top of each other willy-nilly. > The popular Linux distros went with "yes" on all those questions, and > confused the issue no end. On that we can wholeheartedly agree. > "Yes" on #1 is pretty clearly a bad idea - it pretty much means you > can't have both vendor-supplied and non-vendor-supplied version of > some package on the system. It also frequently means that you are forced to choose between vendor and non-vendor supplied packages for a whole slew of other supporting packages like libraries and it opens you up to nightmare scenarios when it comes time to patch or upgrade. [...] > "Yes" on #3 isn't so bad. I think there needs to be a clear > distinction between "this software is maintained, tested, built and > supplied by the vendor" vs. "this is a vendor-blessed build of third > party software, but it is *not* maintained, tested or supported by the > vendor", including having them on separate update cycles. Having two > separate repositories makes those things easy to do, but it's not > clear it's impossible with just one repository. One nit here, the distinction is between "software that is built, maintained, tested, supported and supplied by the vendor" and "software that is not built, maintained, tested, supported and supplied by the vendor". If you want to further delineate the second group into "3rd part software blessed by the vendor" and 3rd party software not blessed by the vendor", that's fine, but it is a different delineation. [...] fpsm _______________________________________________ opensolaris-discuss mailing list [email protected]
