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>

Reply via email to