On Wed, Apr 26, 2006 at 01:28:46PM -0700, Alan DuBoff wrote:
> >From my perspective this software is no different than any other software
> >that
> is installed by a local admin. Why would you feel that adding software to
> /opt is different than to /usr/local?
The difference is that this software has been built and tested as a
unit and delivered by a "vendor" (whether you think of that vendor as
Sun or as a collaborative open team is irrelevant). In other words,
the choice of software as well as how it was built was not made on
site.
> What it solves (to me) is the mis-alignment with Solaris in the open
> source world. By default all the software builds and installs to
> /usr/local. It offers the abiltiy for people to take open sources
> and build and install them in the same fashion they are accustomed
> to on other platforms.
>
> You simply "./configure", then "make", or "make install", and you don't have
> to worry about any environment setttings, obfuscated arguments to configure,
> etc...
First, that approach rarely produces anything useful. In the broken
autotools regime, it's necessary to pass a surprising number of
environment variables and options just to get any nontrivial component
to find the *system* libraries, to say nothing of the rest of the
FormerlyKnownAsTheCompanion stack.
Second, if you're trying to help the site administrator, delivering
software in /usr/local is the last thing he wants; when he uses
autotools to build his own software, it's much more likely to pick up
our stuff even if that's not what he intended, and if he overwrites
our stuff it may break:
- Packaging/Upgrade
- Other components in our stack
- Other components in his own stack that may (knowingly or
not) rely on the component he overwrote
- Ultimately, his will
Isolating our stack in /opt/JustThinkOfItAsTheCompanion still allows
local staff to populate /usr/local without having to worry about all
those nasty autotools options (well, unless they actually want the
software to work, but that's not our fault) and install their own
preferred versions there. They can choose whether to depend only on
their own stack (most cases) or only on our stack (perhaps a few
cases) or on both (danger Will Robinson!). That's flexibility they
don't have if we start delivering stuff into /usr/local. Making it a
symlink suffers from all of these problems and has the added detriment
of being confusing.
Finally, /usr/local is only a default. There's a reason that prefix
can be changed. We change it. Sun changes it for the autotools-based
stuff in SFW and JDS. Red Hat changes it. Debian changes it. Gentoo
changes it. pkgsrc and ports change it. In fact, pretty much every
single software distributor in the world changes it, exactly to
preserve the site administrator's flexibility and deliver a clean,
integrated software stack. /usr/local is an instrument of site
policy. It is absolutely not acceptable for any software stack not
built on site in accordance with site policy to deliver anything to
/usr/local.
--
Keith M Wesolowski "Sir, we're surrounded!"
Solaris Kernel Team "Excellent; we can attack in any direction!"
