further package removals/potential package removals

[Jeff Johnson]

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