[indiana-discuss] "no scripting zone" and isaexec(3C) == architectural

[Nicolas Williams]

On Fri, Jun 05, 2009 at 08:59:24PM +0200, a b wrote:
> > I agree. This has to be avoided. That does not mean that there's no
> > way to enable third-party delivery into /usr (see my other reply).
> 
> Which one are you referring to?

<20090604215017.GI1049 at Sun.COM>, I think.

> > PSARC certainly has discussed these issues at length. This is the first
> > I hear that where third-party software goes is different for Nevada than
> > for OpenSolaris. And I'm not sure that that's anything other than
> > Shawn's opinion -- documentation is needed.
> 
> Indeed.  Documentation is always good, and precise specifications are best.
>  But what is unclear to me is whether ARCs apply to "Indiana".
> 
> Do they?

My impression is that the project will go to the ARC at some point.
They have, for inception of IPS, for example.

As of right now, OpenSolaris is clearly not a product reviewed by the
ARC, but the vast, vast majority (close to 100%) of it is ARC-reviewed,
and I don't see why the bits that haven't been reviewed yet would not
pass muster.  And also, just because something's not reviewed doesn't
mean that it can't be documented -- documentation is a crucial part of
the problem in this thread (death to /opt: Shawn's opinion, or
OpenSolaris law of the land?).

> > I'm not sure I agree because I'm not sure that what Shawn said about
> > /opt is anything other than personal opinion. IMO if IPS can deal
> > sanely with conflicts, and preferably a registry is provided, then
> > recommending /usr over /opt may be a good idea, but deprecating /opt
> > wouldn't be a good idea for a long time yet.
> 
> Getting software *like* for instance Veritas cluster or VxFS + VxVM would be
> difficult if it were delivered into /usr, for the simple reason that such software
> delivers utilities which are named the same, since they are meant to offer
> enhanced yet different functionality that what is in the base system.  And while
> Veritas software might be able to avoid such conflicts (it is just an example), it
> has more to do with concept of "tramping on eachother", which /opt, /etc/opt,
> and /var/opt solve quite elegantly.

I don't agree.  Third parties should not be replacing parts of the
system -- they should be plugging into the system.  In the particular
case of third party filesystems that means delivering kernel modules,
mount_<something>, etcetera (and, because some parts of the filesystem
infrastructure are not Committer, interface contracts are needed).

> Delivering software directly into /usr would be the easiest thing to do, but only
> the distribution vendor may do it safely; and anybody who is not a distribution
> vendor, or cannot afford the effort of integrating, or cannot afford to have their
> software bundled with the distro, is stuck without /opt, /etc/opt, and /var/opt.

Not necessarily.  A registry, for example, would allow us to solve that
problem.