Bugzilla Bug 122089

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.

This is supposed to be fixed in portage-2.2_pre5 or earlier.