Summary: | KeyError: 'CDEPEND' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Green <mikey> |
Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | VERIFIED TEST-REQUEST | ||
Severity: | normal | ||
Priority: | Highest | ||
Version: | 2005.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Mike Green
2005-12-28 08:25:52 UTC
Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r1, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2 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 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks nodoc noinfo noman sandbox sfperms strict" GENTOO_MIRRORS="http://code.server.com/web-servers/" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage-web-servers" SYNC="rsync://code.server.com/portage-web-servers" USE="x86 alsa apache2 apm arts avi berkdb bitmap-fonts bzip2 crypt cups eds emboss encode expat foomaticdb fortran gdbm gif gmp gnome gstreamer gtk2 imlib java jpeg kde libg++ libwww mad mhash mikmod mmx motif mp3 mpeg mysql ncurses nptl ogg oggvorbis opengl oss pdflib perl png python quicktime readline sdl spell sse ssl tcpd truetype truetype-fonts type1-fonts udev vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS Well, upgrade portage to latest stable (2.0.53) in a normal way (not -G) and reopen if the problem still occurs then. There's nothing we could fix with versions that are no longer in the tree. (In reply to comment #2) > Well, upgrade portage to latest stable (2.0.53) in a normal way (not -G) and > reopen if the problem still occurs then. There's nothing we could fix with > versions that are no longer in the tree. > Not possible, I have over 20 servers to install, including the gcc migration. I can provide a binary copy of whatever package version you desire if that would help. (In reply to comment #3) > Not possible, I have over 20 servers to install, including the gcc migration. > I can provide a binary copy of whatever package version you desire if that > would help. > Well sorry, not possible to fix non-existant portage versions; run emerge -u portage and see if it fixes the issue. (In reply to comment #4) > (In reply to comment #3) > > Not possible, I have over 20 servers to install, including the gcc migration. > > I can provide a binary copy of whatever package version you desire if that > > would help. > > > > Well sorry, not possible to fix non-existant portage versions; run emerge -u > portage and see if it fixes the issue. > Like I said, it is not an option to manually run a gcc migration on 30 production servers from source instead of binary packages. It is not going to happen. Nice to know that portage will completely break itself over a 3 month period when it comes to installing binary packages. Thanks a lot for that. I will find a workaround that does not involve taking up to 80 hours of my time. I can provide a working stage3 tarball with the old version of the portage and the snapshot, as well as a stage3 tarball with the current versions, if someone is actually interested in looking at it. As far as I am concerned this is a critical blocker bug in portage. I can't help but wonder what will happen when people try to upgrade GRP installed boxes after the next release comes out. (In reply to comment #5) > Like I said, it is not an option to manually run a gcc migration on 30 > production servers from source instead of binary packages. It is not going to > happen. What are you talking about? Just upgrade portage itself (and needed portage deps), NOT world or gcc or whatever else. We can't fix non-existant portage versions, no point in reopening this bug unless you are able to reproduce it with 2.0.53. (In reply to comment #6) > What are you talking about? Just upgrade portage itself (and needed portage > deps), NOT world or gcc or whatever else. What I am talking about is that I use binary packages to deploy upgrades, I have uptime and security requirements that don't fit into manually upgrading portage from source on every server. > We can't fix non-existant portage versions, no point in reopening this bug > unless you are able to reproduce it with 2.0.53. I found a workaround: emerge -1 --nodeps -G binutils-config emerge -1 --nodeps -G binutils emerge -1 --nodeps -G gcc-config emerge -1 --nodeps -G gcc emerge -1 --nodeps -G glibc emerge -1 --nodeps -G linux-headers emerge -1 --nodeps -G python emerge -1 --nodeps -G portage From that point forward portage gives me an "emaint found errors in your world file" message and then proceeds to function as expected. Closing. |