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 -
_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel
