Well, in fact... the more I think about wrappers, the more I like the
idea.  We loose the ability to link to manual pages (I'd not rather
mix wrappers and links for consistency), but I think there is a simple
solution:

We can bundle a template manual page with the package.  Then, when a
new wrapper is installed, we generate a manual page on the fly based
on the generic one (basically, filling gaps) that explains that the
manual page corresponds to a generic wrapper.  It'd also have to
tell the user how to determine which program the wrapper is pointing to
(basically "wrappers status <program>") so that he knows which real
manual page to look at.

Another advantage that you outline is the ability to make them point
easily to out-of-prefix stuff.

This could even simplify dramatically the changes I've had to do in the
Java packages to make this work (changes that I don't like very much).

Buuut, this framework could be useless to manage anything other than
manual pages and programs.  Anyway, this was the initial plan, so not
a real problem.

How does this sound? :)

Cheers,


On Thu, 2005-01-20 at 11:11 -0500, Todd Vierling wrote:
> On Thu, 20 Jan 2005, Julio M. Merino Vidal wrote:
> 
> > > : Also note that the links go this way: /usr/pkg/bin/vi -> sysconfdir/vi
> > > : -> /usr/pkg/bin/nvi.
> > >
> > >   I would prefer collecting all alternatives under one subdirectory of
> > > sysconfdir (such as sysconfdir/alternatives).  Also, simply using the
> > > basename of the file as the name of the symlink under sysconfdir might
> > > lead to conflicts.
> >
> > 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"?  :)
> 
> 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.
> 
> > I only see a solution to this, which is to use wrappers instead of
> > links.  This way, the wrapper might check if the expected program
> > is available, and fall back to another one in case it's not.
> > Dunno if it's 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].
> 
> 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.
> 
-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/