Havoc Pennington wrote:
On Sun, 2005-01-23 at 06:16 -0500, Jeff Johnson wrote:
Seriously, dependencies have a context, and it's highly unlikely
that the dependency is actually needed by anaconda to install
or remove nautilus. The hint to depsolvers like anaconda necessary
with current implementations to discover an additional edge in
the dependency tree graph could be handled in other ways,
if nautilus were prepared to deal with the dlopen failure at
run-time.
nautilus does not require the SMB backend to work, however we do want it installed by default (even on upgrade).
If (as it does now) that means some people have to keep it installed even though they don't want it,
then too bad; it's simply more important to get it
installed by default.
If someone fixes it so there's no tradeoff (we can get it by default, *and* you can uninstall it), then fantastic; of course nobody will object.
A "requires(missingok)" sounds fine to me, but the anaconda guys are the ones whose opinion
counts.
The mechanism was proposed several months ago, and I'm perfectly willing
to commit rpm to a bit the dependency context bit fields that supplies a mechanism
of "missingok" (i.e. supply hint to the depsovers, which can do whatever they
wish semantically with the bit delivered, on return rpmlib is permitted to blithely
ignore the dependency after delivery).
I have heard nada, zippo, nil, nothing except <shrug> from the depsolver maintainers.
Open an RFE please, and ask for explicit sign off from the depsolver crowd, if you
truly wish the functionality. The implementation is nothing more than testing a bit
in 3 places and arguing whether "missingok" is the appropriate token for the mechanism,
as the semantic is entirely opaque to rpmlib (which supplies mechanism only).
Think: about 3 hours work in rpmlib.
73 de Jeff
