Summary: | global updates are not performed on /var/db/pkg/*/*/*DEPEND | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Florian Engelhardt <flo> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | major | Keywords: | InVCS |
Priority: | High | ||
Version: | 2.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 216231 |
Description
Florian Engelhardt
2006-02-08 01:06:21 UTC
Don't restrict bugs... do you have FEATURES="fixpackages" and if not, run fixpackages. Ironically I hit the same thing today ;) i allread did a "emerge x11-xorg -v" without the binary package, but i will try to update to xorg-x11 7.0, so maybe i will hit this problem again. The underlying problem here is that we do not currently use "global updates" from $PORTDIR/profiles/updates/ to update dependency metadata in the vdb (or binpkgs for that matter). The problem is sidestepped in other cases by pulling the latest dependency metadata from the portage tree. (In reply to comment #4) > The underlying problem here is that we do not currently use "global updates" > from $PORTDIR/profiles/updates/ to update dependency metadata in the vdb (or > binpkgs for that matter). The problem is sidestepped in other cases by pulling > the latest dependency metadata from the portage tree. > Er, I was under the impression that "fixpackages" updates the metadata from global updates, maybe I need to look at the code again. Although for the problem I encountered, running fixpackages seemed to fix the issue. (In reply to comment #4) > The underlying problem here is that we do not currently use "global updates" > from $PORTDIR/profiles/updates/ to update dependency metadata in the vdb (or > binpkgs for that matter). Ehm, that's the whole point of "global updates", where/why did you get the impression that it's not used? There does seem to be some case(s) where vdb entries aren't updated that has slipped in again though. I've noticed it a couple of times locally but haven't taken the time to pinpoint it yet. # tail -n 1 /home/gentoo/rsync/profiles/updates/1Q-2006 move sci-mathematics/ktechlab sci-electronics/ktechlab # echo sci-mathematics/ktechlab >> /var/db/pkg/sys-apps/portage-2.1_pre4-r1/DEPEND # touch /home/gentoo/rsync/profiles/updates/1Q-2006 # emerge -p ... Performing Global Updates: /home/gentoo/rsync/profiles/updates/1Q-2006 ... # tail -n 1 /var/db/pkg/sys-apps/portage-2.1_pre4-r1/DEPEND sci-mathematics/ktechlab By the look of the above, it looks to be like an incorrect optimization of assuming that individual files don't need to be checked for package keys if a package of that key is not installed. (In reply to comment #7) > By the look of the above, it looks to be like an incorrect optimization of > assuming that individual files don't need to be checked for package keys if a > package of that key is not installed. Yeah, we need to do away with that incorrect optimization. We can optimize it differently by batching up all the updates so that files only need to be processed once. I've already done this optimization for the update_ents part of fixpackages (revisions 2721 to 2727). Now it needs to be done for the move_ent parts. I'm planning to create a tool specifically for updating /var/db/pkg/*/*/*DEPEND. It's too time consuming to scan the dependencies of all installed packages during the normal "global updates" routine. After this is fixed, I'd like to apply my patch for bug #48195. Just make sure you don't convert it back to the huge ass pipe it used to be (with 500% increased runtime). The script that I have in mind for this bug will basically work the same way as fixpackages, but it will work on /var/db/pkg instead of $PKGDIR. fixpackages used to take a ridiculous amount of time because it processed each quarter separately (separate passes over the *whole* repo for *each* quarter). I've since fixed it to do all the quarters in one pass and the fix for this bug should work in the same way. I have an experimental tool available here: http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/vdb-tools.py It has a --move mode that appies all the package updates and a --transfer mode that transfers dependency data from the portage tree to /var/db/pkg. --transfer is really fast, and it is helpful when you have installed packages with bad dependency strings that have since been updated in the tree (seems to be common when running ~arch). In svn r6652 I've added new emaint targets called "moveinst" and "movebin" that perform package moves on all of the metadata in the installed and binary packages. This is supposed to be fixed in portage-2.2_pre5 or earlier. This is supposed to be fixed in portage-2.2_pre5 or earlier. |