Subject: Re: HEADS UP: Alternatives system added
To: None <tech-pkg@netbsd.org>
From: Pavel Cahyna <pcah8322@artax.karlin.mff.cuni.cz>
List: tech-pkg
Date: 01/25/2005 22:26:42
Hello,

> On Tue, Jan 25, 2005 at 09:42:17PM +0100, Pavel Cahyna wrote:
> > Shouldn't there be also
> > 
> > pkg_alternatives list vi    # List all available packages which provide vi
> > pkg_alternatives display vi # show status of the vi wrapper
> > pkg_alternatives manual vi nvi # Select nvi as a default for vi
> 
> You should read the manual page.  In the previous mail, I said "_some_

Yes, I should :-)

> commands to play with", but there are much more.
> 
> > Why is the latter needed? Suppose that openssh is an alternative for 1/
> > ssh (the other alternative being ssh2) and 2/ rsh (the other alternative
> > being e.g. heimdal). One then would want to handle those cases separately.
> > E.g. select openssh as default for ssh, but heimdal for rsh. Etc.
> 
> In this case, openssh could register itself as an alternative for ssh,
> ssh2 and rsh.

No, ssh2 is an alternative for ssh (I mean the security/ssh2 package).

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

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?

Thanks and bye	Pavel