> 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.
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).
-John
