[Yum-devel] [PATCH] Use state-aware filename rpmdb index if rpm supports it

[Panu Matilainen]

On 08/31/2011 05:59 PM, James Antill wrote:
> On Wed, 2011-08-31 at 11:44 +0300, Panu Matilainen wrote:
>> This fixes some cases where yum depsolver and rpm>= 4.9.0
>> disagree on dependencies on removal (including but not limited
>> to the example in BZ 729973), causing "ERROR with transaction check
>> vs depsolve" errors. The state-aware file index is currently only
>> in rpm.org HEAD but likely to get backported to 4.9.x series.
>
>   This is altering searchFiles() ... and changing it from "search for any
> rpms that own this file" to something a bit like "search for any rpms
> that own this file, _and_ that file is marked as 'on disk' by the
> rpmdb".
>
>   Pretty sure we can't do that.

Well, that's how rpm behaves now, and unless yum does the same you'll 
get bugreports from the cases where rpm and yum disagree.

Think about it - how can a package claim to own and provide a file that 
is not 'on disk'? Me thinks the only reasonable answer to that is: it 
cannot. It's not just dependencies, but also the other aspects of 
'ownership': no version of rpm removes files whose status is not 
'installed' on package erasure, so the 'non-installed' files are as good 
as orphan files.

>
>   I guess we could add a new API ... but using that API for file requires
> logic, when we'd have to ignore our current caches, seems less than
> optimal.

Optimal or not, I just think correctness should always come before speed.

>
>> Also it requires 'yum clean rpmdb' on first go to wipe previously cached
>> data, pointing out another problem: the state-aware files index is dynamic,
>> and should not be cached across transactions as a transaction can change
>> file states of packages that aren't included in that transaction.
>
>   How well does that work now (installing foo-1.i686 after foo-1.x86_64
> was already installed?)

Installing foo.i686 after foo.x86_64 in the normal multilib 
configuration typically doesn't change anything outside foo.i686, it 
just gets any shared elf-files marked with "wrong color". It's the other 
way around where ownership changes: if foo.i686 is installed first, and 
then foo.x86_64 in another transaction, foo.i686 loses ownership of 
shared elf-files. Released rpm versions change the foo.i686 states 
(incorrectly) to "replaced", current HEAD uses "wrong color". The "wrong 
color" vs "replaced" difference is academic though, both have the effect 
of not owning the file anymore.

>   And while it's "dynamic" it isn't random, so we could act on the
> knowledge of what happens.

Maybe, although I can't think of any way to easily find that out inside 
yum, without duplicating some seriously expensive calculations that rpm 
does. The whole point of the new state-aware (pseudo) index is to export 
that data in an "easy" way to API users.

	- Panu -