* Peter Tribble <P.Tribble at herts.ac.uk> [2006-05-01 13:36]:
> On Mon, 2006-05-01 at 19:15, Stephen Hahn wrote:
> > 2. Discussion
> >
> > In an attempt to provide a more complete offering for software
> > developers on OpenSolaris distributions (as well as other goals),
>
> What other goals?
I had hoped that we would begin to settle on stable guidelines about
integrating freeware. Historically, the consolidations are been left
to figure out aspects for themselves and review them with one or more
ARCs, but those cases haven't been all tied together into one
self-consistent decision tree.
> > this case proposes the introduction of /usr/gnu as a location for
> > | alternate implementations of standard tools produced by the GNU
> > | project.
>
> What's the definition of GNU software? I would presume software
> categorized by GNU as "Official GNU software".
Eligible components for /usr/gnu are those in the FSF/UNESCO Free
Software Directory.
> And are we talking about the complete set of tools on the
> official GNU list, or just a subset - and what determines the
> subset?
It is the subset that are believed to conflict with existing (or
alternative) implementations of a command with the same name.
> What happens to other open source software?
Other software is already covered by 2005/185: it goes in /usr/bin if
it's believed sufficiently important ("business reason") and stable
("architectural reason").
> > This case supplements PSARC/2005/185, "Enabling
> > | serendipitous discovery" [1]. The goals of the two cases are
> > | aligned; this case may propose refinements to the handling of
> > | specific scenarios.
> >
> > 2.1. Expected use
> >
> > | Much like the use of the XPG4 [2] and XPG6 [3] environments, the
> > | expected use of the /usr/gnu environment is to prefer its
> > binary components to the system defaults, via a setting like
> >
> > PATH=/usr/gnu/bin:...:/usr/bin
> >
> > | Traditionally, the commands environments are incomplete: they do
> > | not provide entries for each and every command available in
> > | /usr/bin. The environments are also proper subsets: there are no
> > | commands that are not also present in the system's default command
> > | environment. Although an environment could be modified to be a full
> > | alternative commands environment, that aspect is left to a future
> > | discussion.
>
> I think /usr/gnu *should* be a full and complete alternative
> environment. The thing's supposed to be self-contained, at any rate:
> I would expect that having /usr/gnu/bin in my PATH but not /usr/bin
> would result in a fully functional GNU environment.
The current proposal obviously doesn't cover that case; the clause
"the thing's supposed to be self-contained" is an assumption that
hasn't been proposed earlier in the discussion.
> I don't see that the analogy with xpg4 and xpg6 is a good one.
The case is proposing the environment--to manage namespace
conflict--in precisely the same manner as those other examples. They
are not merely analogous; they are models.
> > | 2.4. 'g' Prefixing
> >
> > Historically, introduction of GNU utilities into /usr/bin has been
> > done with a 'g' character prefixed to the utility name. This
> > proposal amends this practice: the 'g'-prefixed version should be
> > provided if already introduced. In cases where another operating
> > system has provided a 'g'-prefixed version, the project team
> > | introducing an otherwise name-conflicting GNU component may choose
> > | to also provide one; otherwise, additional 'g'-prefixed components
> > | in /usr/bin are discouraged.
> >
> > | GNU components that do not conflict with existing or anticipated
> > | components in the system's default commands environment should not
> > | be placed in /usr/gnu, and do not require 'g'-prefixing.
>
> I disagree with this, strongly. For the first thing, GNU components
> should be placed under /usr/gnu for consistency - if GNU foo is in
> /usr/gnu/bin, I would expect GNU bar to be there too. What's being
> proposed ends up with commands being randomly located based solely
> on the arbitrary sequence of characters in their name rather than
> on any technical basis.
I disagree that namespace management is non-technical.
Most of your subsequent arguments are based on the "completeness of
the environment" issue; if you abandon that complaint, do any of the
these concerns still hold?
> Another problem I have with this is that if I need to override a
> utility (for example, if I need to use a utility from blastwave)
> then I would be forced to place the alternative tools location
> ahead of /usr/bin, therefore overriding (potentially) the whole
> Solaris toolset rather than just the pesky GNU commands I needed
> to.
I don't believe that this case makes that situation particularly
different than how it is today, unless you mean that the current path
management as a whole is inadequate.
> This also elevates GNU to a privileged position - what if some
> other toolset (BSD, for example) were to be integrated?
Nothing in this case precludes the introduction of another commands
environment.
> In other words, GNU software should *all* go into /usr/gnu, with
> presence in /usr/bin (or wherever) being determined individually.
The proposal is based on accepting the tenets of 2005/185, "Enabling
serendipitous discovery". Both it, and its precursor case, cannot
help but be controversial, because they are attempts to express the
tension between precise namespace control and ease of finding
executables in the default configuration.
> Ultimately, I am unclear as to the precise goals of this proposal.
> A simple "provide the entire GNU toolset under /usr/gnu" proposal
> is something I can understand and support, and could be a valid
> part of meeting other goals. (Or even, "provide a well-defined
> subset of all GNU software under /usr/gnu".)
It is not doing that: it is providing a GNU commands environment,
populated according to need, where those commands conflict with
the locally expected version in the system default environment.
This case is not the list; it's what you do if you have a member to
add to the list.
> On my previous system I provided /usr/local/gnu for essentially
> the same purpose. What we discovered was that this created
> enough problems when hidden at the end of the path, and total
> chaos when at the start of the path; enough so that we rapidly
> went back to a fairly minimal exposure of the GNU utilities
> in the default path (and with a g prefix). General user
> behaviour suffered if it was early in the path - we had a lot
> of old scripts break (some because they expected ucb behavior);
> problems arose when building software (I can't remember the
> details, but something along the lines of version mismatches
> between the autotools we had and that used to develop the
> software we were trying to build - but this was some time ago
> when the autotools were evolving rapidly and may not be the
> case today).
Noted.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
