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?
The popular Linux distros went with "yes" on all those questions, and
confused the issue no end.
"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.
However, this doesn't mean that "yes" on #2 is a bad idea. The BSD's do
that, and it makes the systems much easier to manage than the old
arrangement still used by ON. You don't have to guess whether a
package config is in /opt/<packagename>/etc or /opt/etc/ and it's
binaries in /opt/<packagename>/bin or /opt/bin - the answer is they're
in the /opt/<type> dir, as there is no /opt/<packagename> dir. The
config files may be in /opt/etc/<packagename> if there are a suite of
them. And executables that aren't expected to be run from the command
line may be in /opt/libexec/<packagename>, but you always start with
the appropriate /opt/<type> directory.
"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.
The Linux distros went from having no vendor-blessed repositories for
third party software - meaning everyone ran their own, resulting in a
situation similar to what ON now has - to having almost all the third
party software in their own repository, with no distinction between it
and the vendor software. This forces all the packages into the distro
update cycle, or worse yet ties large chunks of those distros to some
critical third parties vendors update cycle.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
