Subject: Alternatives, 3rd attempt
To: None <>
From: Julio M. Merino Vidal <>
List: tech-pkg
Date: 01/24/2005 00:31:08
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:

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 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 :)


Julio M. Merino Vidal <>
The NetBSD Project -