On Thu, 2005-01-20 at 11:11 -0500, Todd Vierling wrote:
> On Thu, 20 Jan 2005, Julio M. Merino Vidal wrote:
> > Yes well, sorry for the terminology.  When I wrote sysconfdir, I was
> > referring to PKG_SYSCONFDIR, which is PKG_SYSCONFBASE/PKG_SYSCONFSUBDIR,
> > and the actual value for the subdir part is 'alternatives'.
> 
> And there's the basename issue.  Should all alternatives be in "bin"?  :)

No, they are not.  The namespace in sysconfdir is flat (as Debian does),
but the alternatives are not...  True, there might be some conflicts,
but if we restrict ourselves to binaries and manual pages (which seems
reasonable enough), this won't happen.

This is how the control files look at the moment:

[dawn jmmv] $
cat /usr/pkg/libdata/alternatives/vi/CLASS                       
/usr/pkg/bin/vi
/usr/pkg/man/man1/vi.1
[dawn jmmv] $ cat /usr/pkg/libdata/alternatives/vi/nvi    
/usr/pkg/bin/nvi
/usr/pkg/man/man1/nvi.1

The names in CLASS get flattened when added to the sysconfdir.

> Perhaps the alternatives should be hierarchical.  For example, for "vi",
> have the class name be "bin/vi", the alternative redirect link be
> PKG_SYSCONFDIR/bin/vi, then linking to the appropriate choice.

This is another possible solution, but as said above, may not be worth
the effort...

> Actually, I would like the idea of wrappers.  This would also avoid any
> possible problems with programs that change behavior based on argv[0].

Changing behavior... I found that.  I tried to add gvim as a provider
for vi, but the GUI didn't appear; heh.

> You could have something like this:
> 
> bin/vi -> alternatives wrapper script with class name substituted in by sed
> (NOT using $0 to get class name, so that users can symlink to the wrapper)
> 
> PKG_SYSCONFDIR/bin/vi -> not a script, but rather a config file for the
> alternatives wrapper listing possible alternatives, in preference order
> (with optional "emulate this program" arguments), e.g.:
> 
>     /usr/pkg/bin/vim
>     /usr/pkg/bin/nvi
>     /usr/pkg/bin/emacs -l vip
> 
> This config file could be updated automagically by logic added to the
> pkginstall script framework, adding newly installed packages to the end
> without regard to ordering.  It would then be up to the admin to reorder the
> file as s/he sees fit (or even add commands not in LOCALBASE!).
> 
> The wrapper would then read the config file line by line, using the first
> one it finds as executable.  Then exec it with proper args, and voila.

Hmm the thing is that this proposal sounds quite well, but what to do
with the manual pages?

Cheers,

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/