Hi again,

based on lots of suggestions from jlam@, I have done multiple
improvements to the previous implementation.  You can find it at the
same place as before:

        ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/alternatives.diff
        ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/alternatives.tar.gz

The changes WRT the previous version are:

- The wrappers can now be managed at package granularity level.  This
  means that you can select a bunch of alternatives based on a package
  name, such as doing 'pkg_alternatives manual kaffe' or
  'pkg_alternatives manual sun-jre15' to manually select one of the two
  implementations, without having to deal with wrappers directly.

  Of course, you can still handle each wrapper independently if you want
  to (using the -w flag).  This allows you to select, for example, a
  specific appletviewer from one implementation, leaving all the other
  utilities belonging to another one.

- Due to the above changes, it's now necessary to keep a list of
  wrapper/alternative pairs on a package basis.  This is done by storing
  an +ALTERNATIVES file in PKG_DBDIR.  (To avoid changing pkg_create to
  support it, it's created dynamically, which is now possible due to all
  the improvements made to the install code today by jlam@.)

  This might allow us get rid of the auxiliary database stored
  in libdata/pkg_alternatives.  I haven't done so yet because it will
  slow down the wrappers quite a bit, specially in systems with lots of
  packages installed.

- And, because we now use a file to store the list of alternatives,
  it's easier to change alternatives.mk to read a file instead of
  multiple variables (not only easier to handle, but also cleaner).

  This means that a package that wants to use the alternatives system,
  only needs to add an ALTERNATIVES file in its package directory, being
  each line an entry for the 'pkg_alternatives -sw register' command
  (i.e., a wrapper/alternative pair separated by a _space_).

I still have to do some minor improvements, like pretty-printing of the
status command (which is quite unreadable ATM), review the manual page,
and some other things.  But overall, I think it's "ready".

I'm leaving this here for review :)

Cheers,

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