Subject: pkg_alternatives as a dependency, again
To: None <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
Date: 02/10/2005 10:56:40
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
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 <email@example.com> <firstname.lastname@example.org>