On Wed, 2011-08-31 at 19:57 +0300, Panu Matilainen wrote: > 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.
Maybe, but I'm worried about cases like: yum install /usr/bin/blah => gets both multilib variants yum provides /usr/bin/blah => only returns one > Think about it - how can a package claim to own and provide a file that > is not 'on disk'? 1. Well it has done in rpm for the last N years :). 2. In some ways this is similar to the user doing "rm -f /bin/zsh" and then asking if zsh owns that file. > > 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. That's far from an absolute rule, as I'm sure you wouldn't argue that we need to have the erlang model of 100,000 provides/requires per. package ... or even taking this case to the extreme means that we can't use "filelists" for anything, so whenever we'd now hit that we should (to be correct) download all the package headers and pass them to rpm? I'm not saying this is a bad thing for rpm to be doing ... but it's not just a simple bugfix to get to 100% "fixed". Eg. I can well imagine people wanting "yum remove foo.x86_64" doing an automatic reinstall of foo.i686 instead of deleting anything depending on /usr/bin/foo. > >> 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. Right, I meant has rpm got rid of the old problems where you could install both packages at the same time but not separately? > > 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. There are a number of ways we could work around it, from rpm telling us which files will go "missing" as part of the transaction ... to just ignoring .i686 dup. files when there are .x86_64 packages, and maybe some way for rpm to say "something weird happened, drop all file caches". On the other side we could fix the file requires lookup APIs in rpm so we don't need the cache anyway (I believe Florian was going to look at this after the NEVRA+pkgid index went in). _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
