* John Levon <john.levon at sun.com> [2006-05-04 11:16]:
> On Thu, May 04, 2006 at 10:00:55AM -0700, Stephen Hahn wrote:
>
> > > For 2), which has happened before, what would we do?
> >
> > Decide, based on the stability of the component, whether to evict it
> > rapidly or not. Has this really happened for a name-conflicting
> > component, or merely across the entire set of OSS software?
>
> I don't believe it has yet happened for a name-conflicting component. Given
> that there is precedent for this happening generally, and we'll be stuck with
> /usr/gnu/ forever, I think we need some kind of plan here.
1. I don't agree that this proposal is required to propose that plan.
2. My recollection is that the cases in which a FSF-to-non-FSF
transition has happened have not been associated with the long
standing Unix-replacing command variants. Citations to the
contrary are desired.
3. The proposed approach handles the multiple conflicting
publishers case cleanly, with a publisher-grouping. If we are
trying to avoid the "random alternative environment" of
/usr/sfw/bin, then any further solution will be additional
hierarchies (requiring path manipulation) or additional prefixing
(requiring source modification), or both. That is, we've
extracted the aspect that forms a common case; what's left are the
special cases--thus, point 1.
> > > I'm a bit concerned that "blessed as a GNU project" is an odd match to the
> > > desired features of /usr/gnu/.
> >
> > It sounds like you're proposing different desired features (which is
>
> I was basing my comment on "desired features" upon the comments during the
> original thread started by John Rice which sparked this proposal:
> as:
>
> "The problem is really down to the various build tools or lack of them on
> Solaris that OSS just expects to be there on a Unix box if it is to be able to
> build with out lots of hair loss on the part of the user."
>
> If that's not actually the primary reason for this proposal, then my
> apologies.
Bart's case on "serendipitous discovery" sets the overall parameters:
get non-conflicting components into /usr/bin, via SFW or other
consolidation. This case is trying to present a specific approach to
handling name conflicts for a believed precise set of utilities.
At this point, I would like to verify that folks are generally
satisfied with this approach to an acknowledged subset of the name
conflict problem, and that we should take it to PSARC for further
questioning.
- Stephen
--
Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems
stephen.hahn at sun.com http://blogs.sun.com/sch/
