In article <1106222131.1075.41.camel@dawn.local> Julio wrote:
: When a package is removed, the alternatives system checks if it was
: the current setting for a class; in such case, it tries to fall back
: to another one in the same class.  If none is found, the class is
: automatically removed.

  I think, the choice should be recorded, so if the package is later
added again, it is selected automatically.  Updates are often done by
removing the old versions of packages and then installing the new
versions.  I think the selected alternative should be the same after
such an update.

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

:  sysconfdir is used here so that this can be
: configured on a system basis if sharing /usr/pkg.

  This is problematic: if nvi is selected as vi on system A, and on
system B -- which shares /usr/pkg with system A -- nvi is deleted,
system A is left with dangling symlinks.

: What do people think?  I would like to get this finished and committed
: soon, if there are no big objections.

  Would it be possible for a package to depend on a alternatives
class?  For instance, foo depends on vi, so either nvi or vim have to
be installed, but foo does not care which one?  If so, this sounds
like a cleaner solution to the bothersome {nvi,vim} style
dependencies.

						yours,
						dillo