Will whomever objected to pkg_alternatives as a dependency of
alternatives-aware packages please contact me offlist?  I want to know what
the objections are.

I have a few cases where a dependency will be critical to make the
alternative substitution work.  (nano vs. pico, unace22 vs. unace, for
starters; see below.)  However, such a dependency will mean that packages
installed *after* the dependency will automatically generate alternatives.

Ideally, I think the dependency should be there to ensure proper maintenance
of the alternatives wrappers.  But I'm open to suggestions of a different
approach.

=====

Why not having a dependency is broken:

Consider nano vs. pico.  A system where nano is needed and pine is not
installed does not need a "pico" per se, but it's useful to have that name.
So editors/nano can be an alternative for bin/pico.

However, editors/pico already has a bin/pico.  We can work around this by
installing it as bin/uwpico or similar, and make that an alternative for
bin/pico; followed by an appropriate CONFLICTS in editors/nano for pico
versions before the bin/uwpico change.  Problem solved -- except if the
admin does not have pkg_alternatives installed, in which case bin/pico
no longer exists when editors/pico is installed.

So we could make pkg_alternatives a dependency of editors/pico.  This solves
the problem automatically, but has the noted caveat above that it triggers
alternatives for any package installed after this point.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>