John Plocher wrote:
> > Joseph Kowalski wrote:
> > What would the counter proposal be?  Everything I can think of has some
> > similar case that will not work.
>
> I see several alternatives:
>
> A) Put all the stuff in /usr/gnu, modify /etc/default/login to add 
> /usr/gnu to PATH
>        [+] new users see the combined environment
>        [-] existing users that didn't set their PATH to include the 
> initial
>            system settings (PATH=$PATH:...) don't
>        [-] all users that wish to interpose their own version are 
> forced to
>            explicitly set PATH to override the default
>
> B) Put all the stuff in /usr/gnu, provide a pkg of symlinks into /usr/bin
>    (etc - see my earlier mail)
>        [+] new users see the combined environment
>        [+] existing users do as well
>        [-] The choice of installing the symlink pkg or not affects all 
> users
>            on a system, not just those that wish to interpose their 
> own version.
>            new users of systems without the symlinks, but with an 
> alternate set
>            of gnu utilities would have access to neither.
>
I Think B I perfectly acceptable.

It's true that the one negative is still system wide, but the admin who 
is choosing not to install it is free to make sure there are other ways 
for his users to find the tools.. either autoamtically or with effort as 
the admin see's fit.


> C) Don't add this source to ON, but rather push the current proposal's
>    pkg creation and glue out to an external consolidation; Sun would then
>    co-ship a release of that consolidation's packages with ON.  (This
>    really starts to smell like blastwave, sunfreeware and friends)
>        [+] new users see the combined environment
>        [+] existing users do as well
>        [+] Motivated admins could build a newer package on their own and
>            upgrade to it; such an upgrade would "just work" with Sun's 
> own
>            upgrade processes; users would not see any difference between
>            the pre and post "gnu upgrade".
>
> Personally, I really like "C", but it presumes that stability, 
> dependency and
> release-engineering concerns could be addressed (I think they can be).
>
C seems idealistic, but also seems like much more work.

 -Kyle

  


Reply via email to