Subject: Re: Alternatives system for pkgsrc
To: Julio M. Merino Vidal <>
From: Todd Vierling <>
List: tech-pkg
Date: 01/20/2005 11:11:17
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
> 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/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.

-- Todd Vierling <> <>