Bart Smaalders wrote:
>
>
> We (OpenSolaris developers) wish to deliver a functionally
> complete system.  It is not a kit car of parts to be assembled
> by skilled users.  To that end, the default install should not
> require mucking around with PATH, etc, to find all the software
> we ship with OpenSolaris.
At the same time you don't want to lose those 'skilled users' who want 
the flexibility to make the system work the way they want it to work.
>
> To that end, I think the proposal as presented obeys the
> principle of least surprise, and should work "out of the
> box" ("off the dvd?") for the maximal number of users.
>
The B option presented would work 'off the DVD' by default for all users.

> Users who wish to customize the bits we deliver into a more
> pleasing form have several options:
>
>  1 They can select between alternate environments provided
>  with OpenSolaris using their PATH variable.
They will be unable to choose the combination of 'Solaris binaries that 
have Gnu conflicts' first , and then 'locally installed GNU binaries' 
second.

That combination is impossible.
>
>  2 They can create a ~user/bin that is a forest of
>  symlinks into various parts of the system to create their
>  own pastiche mixing traditional Solaris, xpg4, ucb and gnu commands.
>
Since ~user/bin would generally be on the network, all the same issues 
with putting it before /usr/bin apply.
Not to mention the Yuck! factor of many users each having to maintain a 
symlink farm.
>  3 They can choose to not install all of the packages
>  that are part of whatever OpenSolaris distro they're
>  running, and provide more desirable bits themselves,
>  either locally or via NFS.
>
This eliminates choice on a per user level. It's only a chouce the admin 
can make.
> In any case, a selection of /usr/bin as the default
> install location for useful binaries of any provenance
> enables the maximum number of users and does not forestall
> either substitution or removal of unwanted components.
>
The softlink option in a post before this one (Option B) also enables 
the maximum number of users and also enables the flexibility for the 
admin to allow other combinations if desired.

'removal' isn't generally what is desired... at least not on a 
system-wide scale. Per user maybe.
'subsitution' is desirable but not in any way that forces removal or 
forces all users to accept it.

In option B, if the admin chooses to leave out the links package, then 
it's up to that admin to educate, update, etc the users or thier 
settings to find these tools.

By default everything will be available to all users which as I 
understand it is the goal.

-Kyle



Reply via email to