Subject: Alternatives, 3rd attempt
To: None <tech-pkg@NetBSD.org>
From: Julio M. Merino Vidal <email@example.com>
Date: 01/24/2005 00:31:08
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
- 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 :)
Julio M. Merino Vidal <firstname.lastname@example.org>
The NetBSD Project - http://www.NetBSD.org/