I just tried to install modular x and made a backup of the xorg-x11 with quickpkg xorg-x11 i now tried to install this binary with emerge =xorg-x11-6.8.2-r6 -vk but i got an error message telling me, that: emerge: there are no ebuilds to satisfy ">=x11-misc/ttmkfdir-3.0.9-r2". (dependency required by "x11-base/xorg-x11-6.8.2-r6" [binary]) But: i have ttmkfdir-3.0.9-r3 installed. discovery x11-base # emerge info Portage 2.0.54 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.16-rc1-mm5 x86_64) ================================================================= System uname: 2.6.16-rc1-mm5 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -Os -ftracer -pipe -fomit-frame-pointer -s -funroll-loops" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -Os -ftracer -pipe -fomit-frame-pointer -s -funroll-loops" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac acpi alsa audiofile avi berkdb bitmap-fonts bmp bzip2 cdr crypt cups curl dga dvd dvdr dvdread eds emboss encode exif expat fam ffmpeg firefox foomaticdb fortran ftp gif glut gmp gstreamer gtk gtk2 gtkhtml guile hal idn imagemagick imlib ipv6 jpeg lcms libwww lirc lzw lzw-tiff mhash mng moznoxft mp3 mpeg msn mysql ncurses nls nptl nptlonly nvidia ogg oggvorbis openal opengl pam pcre pdflib perl png python quicktime readline recode sdl slang spell ssl svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales utf8 v4l v4l2 vcd vorbis xine xml2 xpm xv xvid xvmc zlib video_cards_nvidia video_cards_vesa video_cards_fbdev input_devices_keyboard input_devices_mouse linguas_de userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
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.