I've added three issues of my own to the bottom; sch-0 is the "why
are you doing this?" issue.
- Stephen
----
jdc-1 The proposal selects /usr/gnu as FSF/UNESCO Free Software, but
why is this the important or useful determinant? More to the
point: what software or user actually targets or would target
operation in an "FSF environment" on this basis?
It's easy to construct an argument for a "similar to [insert
distribution here] Linux" environment for people adopting
Solaris, or for those using Solaris within a mixed environment
(something that likely is true for _most_ Sun customers).
However, FSF isn't precisely Linux, because distributions of
the latter are typically a superset.
Similarly, "XPG4" is a complete, standards-conformant
environment. Users expect it to exist on other systems, so
there's an argument for allowing selection of that
environment.
Is there an equivalent to "the GNU environment" on any other
system? If not, then what interoperability story are we
trying to sell?
The choice of the GNU packages of the FSF/UNESCO list is an attempt
to recognize the FSF implementations of longstanding Unix commands
as a second source of these commands, with wide acceptance across
operating systems. In particular, this wide acceptance means that
various other software components of interest to OpenSolaris are
becoming dependent on the FSF/GNU implementations, at least in the
build phase. This proposal attempts to share the effort of
maintaining these tools, by virtue of housing them in the SFW
consolidation. (See sch-0 below for more.)
I don't believe there is an equivalent competing set of command
variants with the same attributes.
Although one could read this case as calling for the complete set of
GNU packages, it does not do so--it is providing a means of
resolving included packages that provide a variant implementation of
existing commands. As such, the notion of equivalence of
environments isn't part of the current argument; the variants being
included are included because the project team (or future teams)
believe the variant of sufficient utility to justify integration.
jdc-2 Where are we heading? The case hints at /usr/sunos. Do we
really want a forest of /usr/foo directories for different
flavors? Is that an architecturally viable system?
It's of course doable; the question is whether it's wise, and
what the criteria are for creating a new /usr/$THING
directory. (Is "gnu" the last one?)
My expectation is that /usr/gnu is indeed the only one of its kind
that we need (although in five or more years I may be shown wrong).
The /usr/sunos notion is a suggestion for fairness in managing name
conflicts, so that, from a packaging perspective /usr/bin is in fact
only populated with non-conflicting commands. Other technologies
are postulated to make /usr/bin appear to be complete, with a
particular subset of variants selected. (But that's why it's in
"Future Work".)
As I note in jdc-1, I don't believe there is an additional large set
of widely used variants that would necessitate a similar
/usr/$THING, future standards efforts notwithstanding.
jdc-3 Nit: make it clear that /usr/gnu/etc and /usr/gnu/var are
explicitly disallowed, and thus just setting the basedir isn't
enough for integration.
Text added.
jmp-0 Scope: Is this an OpenSolaris-wide proposal or a Solaris-specific
one? i.e., would we expect Nextenta to follow this lead?
My working position is that ARC review is a choice of each Community
providing a consolidation. Solaris, as a Distribution, elects to
make itself out of only consolidations that have pursued ARC review.
Nexenta, as a Distribution, may or may not choose to take the
published output of each consolidation; further, it may choose to
take only the parts of each published consolidation it deems
interesting--which could in fact lead to outcomes other than those
catalogued in the ARC cases that led to the current form of a
particular consolidation.
So, this is an SFW-specific proposal, that various OpenSolaris
distributions may choose to follow by virtue of including the SFW
consolidation's output.
jmp-1 This proposal puts a set of OSS utilities in /usr/bin where
they become intermingled with core Solaris commands. It also
puts conflicting commands in /usr/gnu. This lets the user
choose between
Solaris versions 1st + Solaris-GNU versions 2nd
(PATH=/usr/bin:/usr/gnu)
and
Solaris-GNU versions 1st + Solaris versions 2nd
(PATH=/usr/gnu:/usr/bin)
It does not allow for
Solaris versions 1st + User-Provided-GNU versions 2nd
That is, if I download/configure/make my own version of the
GNU utilities, I am faced with either using them to the exclusion
of any Solaris versions (PATH=/myGNU:/usr/bin) or not using them
at all. There is no way for me to use the Solaris versions 1st
and my GNU versions 2nd.
(I think a key aspect of this case is that it is primarily focussed
on managing conflicting binaries. As a result, the first example,
PATH=/usr/bin:/usr/gnu/bin, isn't actually fully simplified--it is
equivalent to PATH=/usr/bin.)
I believe the issue raised concerns the provision of a
/usr/local/bin/foo, and selecting its preference on a per-command
basis against /usr/bin/foo and /usr/gnu/bin/foo. It is true that
the path mechanism in Unix always chooses the first executable found
in the list of paths given in the environment, which leads to
relatively crude outcomes when considering individual commands
implementations. The proposal attempts to utilize the solution in
place for other command variant collections (UCB, XPG4, XPG6).
Remediation is available to local sites by placing a preferred
subset of commands and placing the path to that subset ahead of the
default entries, or via omission of the SFW package(s) delivering
conflicting functionality. This omission may cause other, dependent
packages to fail installation.
sch-0 Why are you doing this?
The proposal to add /usr/gnu as a filesystem tree is based on the
costs derived from (a) the absence of these implementations on a
system based on OpenSolaris consolidations, and (b) the reliance on
filename prefixing to resolve conflicting variants of well-known
Unix commands. The JDS and SFW consolidations bear these costs in
common, but were providing duplicate solutions in the form of
carrying a private build environment (JDS) or porting software to
utilize alternate command variants, or alternate command names
(SFW). More recently, the Xen project in ON declared dependencies
on a variety of OSS components for its build and operation.
sch-1 /usr/bin should not be populated with OSS/GPL-licensed software.
The SFW consolidation (and the other active consolidations) attempt
to be pragmatic about the software they include: if a large
collection of developers or users would benefit from the inclusion
of some software, and that software can be maintained at the
declared stability levels while remaining within the resource
constraints of the project teams involved, then the software is a
suitable candidate for integration.
Comments about a potentially license-restricted set of commands,
perhaps achieved via packaging or new filesystem locations, are
interesting, but contradict existing cases, like PSARC/2005/185,
"Enabling serendipitous discovery", as well as the other OSS
inclusion precedents. Changing this direction will require
discussion beyond the scope of this case.
sch-2 What about other implementations of various Unix commands?
Although this case expresses the position that the FSF/GNU
collection is the de facto alternative to the command variants
historically associated with OpenSolaris, it does not actually
propose a command variant replacement policy. The historic variants
remain in /usr/bin, and remain the default choice. New command
variants, on their individual merits, can of course be added via
integration in an OpenSolaris consolidation. Such additions should
be viewed in two parts: a means of resolving name conflicts with
existing variants (usually by executable name prefixes, or alternate
names), and a proposal that the default variant be replaced by the
new variant. As has been observed in various cases, the latter is
substantially more involved.
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
