Subject: Re: Alternatives system for pkgsrc
To: Todd Vierling <firstname.lastname@example.org>
From: Julio M. Merino Vidal <email@example.com>
Date: 01/20/2005 19:02:17
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
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? :)
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.
> 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/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 <firstname.lastname@example.org>
The NetBSD Project - http://www.NetBSD.org/