> On Tue, Jan 25, 2005 at 10:26:42PM +0100, Pavel Cahyna wrote:
> > 
> > > You can set openssh as the default as a whole group of wrappers (like
> > > "pkg_alternatives manual openssh"), which could select all the binaries
> > > provided by it as the defaults for ssh, ssh2 and rsh.
> > > 
> > > But you can tune each independent wrapper to suit your needs (as in
> > > "pkg_alternatives -w manual bin/ssh /usr/pkg/bin/openssh-ssh" or
> > > however the binary could be called).
> > > 
> > > Hope this helps,
> > 
> > I still find it a bit insufficient. Mainly because of a lack of larger
> > wrapper groups. Imagine ssh - this is not only the bin/ssh program, but
> > also the tools like ssh-agent, ssh-keygen, etc. Having to select them
> > individually is too much granularity IMHO.  All those should be in one
> > "wrapper group". Debian's alternatives have this - they call it "link
> > groups" and they are referenced by their "master link". If the master link
> > changes, all other links in that group (the "slave links") change too.
> 
> I started with an implementation similar to this one.  Was hard to manage
> and introduced some limitations.  Although I agree that in some respects,
> was nice.

Please, couldn't the groups be added to your current implementation, too?

> > Also, I read:
> > "If running as `@ROOT_USER@', the system configuration file is modified;
> > otherwise, the user configuration file is changed."
> > 
> > Isn't this a bit stupid? Why not allow root to be able to modify his own
> > alternatives configuration?
> 
> I forced root to use the system-wide database so that 'sudo vi' and
> similar commands always use a known list of alternatives, instead of
> possibly looking in the user's home directory.

I believe this effort is vain, because:

$ sudo env
...
PATH=/home/pavel/bin:/bin:/sbin:...
...

You see? Why to use a known list of alternatives when other pieces of
environment are still pointing to the user's home directory?

Bye	Pavel