The problem with installing into the global zone that not all zones might be
allowed to have the exact same software stack.
This is especially true when the global zone must be kept lean & clean.
For example, one (sparse) zone might need to run one particular version of
Oracle (I'm using Oracle as an example because it's the first thing that came
to mind), for example standalone Oracle 10.2.0.4, while another (two) zones
might need RAC, while yet another zone might need 11.1.0.6, and while yet
another zone needs only Oracle client.
Same thing could be applied to just about any piece of software; for example,
Python, which is a perfect example of a piece of software whose revision can
have serious effects on applications, and which is not designed to run
side-by-side (unless additional engineering is thrown at it) on the same system.
This applies to just about any software.
Now, for a single desktop system, it might or might not matter, but I believe
that our job is to educate people that just because someone cooked something up
on GNU/Linux, that doesn't make it function correctly.
I'm really, really unsure about what you mean by "and we have to keep it
working to avoid frustration", because I've got literally hundreds of open
source packages from GNU/Linux and FOSS that I compiled, linked, and packaged
by myself into /opt, /etc/opt, and /var/opt.
In fact, all I do nowdays is making RPMs on GNU/Linux (both RHEL and SLES), and
even there, I have the rpmbuild(1) command build RPM packages in /opt (and
/var/opt, and /etc/opt) without any major problems whatsoever.
So there is no need to use /usr/local on GNU/Linux (and in fact, the Linux
filesystem specification says to use /opt, see link below), so I fail to see
how "keeping /usr/local because of Linux" is even relevant here.
Here is the link to Linux standards base ("LSB") specification, and in
particular, to chapter 16., which is the filesystem hierarchy standard ("FHS"),
please read it when you have some time:
http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html
The lesson to take away from using /usr/local, and from doing so in the global
zone, is one of architecture: it can have serious repercussions, if not thought
about in advance.
Old Romans said: "prevention is the best cure", so the best thing to do in
order to avoid these architectural headaches is to teach people to stay clear
of /usr/anything in general, and /usr/local in particular.(/usr is simply off
limits to anybody but the OS/distro vendor, so one should learn that pretty
early on. This applies to GNU/Linux as well, not just (Open)Solaris.)
Date: Wed, 24 Mar 2010 16:28:53 +0100
From: [email protected]
To: ug-chosug at opensolaris.org
Subject: Re: [ug-chosug] Getting Firefox 3.6.2 in your favorite language on
OpenSolaris!
Hello,
I don't want to enter into this subject, but I think it is important to clarify
one point that may scare people:
- If you install packages that use by default /usr/local as root directory you
will be able to install sparse zones.
- If you put some contents into /usr/local in the global zone, you will get it
available in the sparse zones, but read-only. You will not be able to add
something for just one sparse zone, but you will still be able to configure and
use the sparse zones without any issue.
/usr/local is still widely used in Solaris (because of Linux), and we have to
keep it working to avoid frustration and to help people when they move to SRV4
systems.
Regards,
Javi
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ug-chosug/attachments/20100324/7f5a6b2e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6g_top.gif
Type: image/gif
Size: 1257 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/ug-chosug/attachments/20100324/7f5a6b2e/attachment-0001.gif>