After emerge sync, emerge -u fails with Calculating system dependencies -Eclass 'xfree' does not exist for 'x11-base/xorg-x11-6.7.0-r2' Reproducible: Always Steps to Reproduce: 1. emerge sync 2. emerge -u world Actual Results: >>> Updating Portage cache... /Eclass 'xfree' does not exist for 'x11-base/kdrive-4.3.0-r5' -Eclass 'xfree' does not exist for 'x11-base/x11-drm-20040827' \Eclass 'xfree' does not exist for 'x11-base/x11-drm-4.3.0-r6' |Eclass 'xfree' does not exist for 'x11-base/x11-drm-4.3.0-r7' -Eclass 'xfree' does not exist for 'x11-base/xfree-4.3.0-r7' \Eclass 'xfree' does not exist for 'x11-base/xorg-x11-6.7.0-r2' |Eclass 'xfree' does not exist for 'x11-base/xorg-x11-6.8.0-r1' /Eclass 'xfree' does not exist for 'x11-base/xorg-x11-6.8.0-r2' ...done! Calculating system dependencies -Eclass 'xfree' does not exist for 'x11-base/xorg-x11-6.7.0-r2' Portage 2.0.51-r2 (gcc34-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20041021-r0, 2.6.10-rc1 i686) ================================================================= System uname: 2.6.10-rc1 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.4 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -mno-sse2" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -mno-sse2" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ds.thn.htu.se/linux/gentoo http://ftp.linux.ee/pub/gentoo/distfiles/ http://trumpetti.atm.tut.fi/gentoo/ http://mirror.pudas.net/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://www.gigaload.org/gentoo.org/ " MAKEOPTS="-j3" PKGDIR="/local/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib alsa apache2 apm arts avi berkdb bitmap-fonts bonobo cdr crypt cups dvdr emacs encode esd f77 foomaticdb gdbm gif gnome gnome2 gphoto2 gpm gtk gtk2 gtkhtml guile imlib java jpeg kde ldap libg++ libwww mad mikmod motif mozilla moznocompose moznoirc moznomail mpeg mysql ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xemacs xml xml2 xmms xv zlib"
Me too. Without being too negative about this, could something be done to stop breaking the portage tree, please? This is the second time in the last week (that I've noticed) that the whole thing has been broken. It shouldn't happen. It shouldn't be possible for it to happen. If it can happen, something needs to be done about it because it does not reflect well on all the hard work put in by Gentoo developers. All of Gentoo gets tarred with the same brush when just one person accidentally leaves the portage tree in a corrupted (and unusable) state. Sorry for sounding critical, but I suppose I am being. phil
"Without being too negative about this, could something be done to stop breaking the portage tree, please? This is the second time in the last week (that I've noticed) that the whole thing has been broken." Previous incident was? "It shouldn't happen. It shouldn't be possible for it to happen." Suggestions are always welcome. Keep in mind ebuilds are basically complex lil pieces of glue. Crap happens, frankly. "If it can happen, something needs to be done about it because it does not reflect well on all the hard work put in by Gentoo developers. All of Gentoo gets tarred with the same brush when just one person accidentally leaves the portage tree in a corrupted (and unusable) state." Mistakes happen, in this particular incident it was A) unknown gotcha of eclasses (#56408), installed pkgs still require the eclass in the tree B) a mistake in the eclass setting, not exposed by purely crappy luck. Keep in mind we're volunteers. Either way, it was resolved about 10 minutes after it was noticed... resync and you'll be fine.
I *do* keep in mind you're volunteers. I am also aware that it is non-deliberate. I am also aware that "these things happen". My point is that it shouldn't be *possible* for it to happen. It shouldn't be *possible* to corrupt the portage tree (certainly not by such a trivial error). I know there are tools for checking the consistency that take too long to run for every change. I'll also ignore the fact that the tree is maintained under CVS, and hence the person who removed the file from CVS must first have removed it from their own area, and a simple "emerge -upD world" on that tree would probably have caught the error before "cvs commit" was performed. Because "these things happen" regardless of how simple or hard it is to do. Again, my point is: developers shouldn't be put in the position that they *can* screw things up. It isn't fair to expect them to not mistakes (and I don't). But they can be helped, and there are certainly ways and means to achieve it (in the worst case, it might add a few minutes into getting the stuff from developer into "published" portage, but that's probably worth it). Yes, I would volunteer myself, but my time is limited at present: between my job, wife. new baby, and house move :-) phil
"It shouldn't be *possible* to corrupt the portage tree (certainly not by such a trivial error)." The tree actually is easily corruptable by a dev making mistakes. It happens occasionally, and those who do it repeatedly get slapped. There really isn't much of a way to curtail that possibility without limiting development, either. "I know there are tools for checking the consistency that take too long to run for every change." No, there aren't for every change. Repoman is a set of quick checks, not a qa standard- repoman flat out missed the initial bug, since qa tools aren't smart enough to catch every potential error in a language as fluid as bash. "it from their own area, and a simple "emerge -upD world" on that tree would probably have caught the error before "cvs commit" was performed. Because "these things happen" regardless of how simple or hard it is to do." You're assuming, and you're wrong. removal of the eclass followed after changes to xorg.eclass. It was a slight of hand, and an easy mistake to make... Again, my point is: developers shouldn't be put in the position that they *can* screw things up. Err... again, that's not possible without stopping development. bash is too fluid to nail down every possible permutation/bad interaction, this is why we don't rely on repoman as our sole QA tool... "It isn't fair to expect them to not mistakes (and I don't). But they can be helped, and there are certainly ways and means to achieve it " Suggest them please then, cause what we have right now is just that- what we have. Automated checks are useful tools, but they can't solve everything- this bug specifically will lead to a tweak in portage removing it from being possible. Yes, I would volunteer myself, but my time is limited at present: As our most devs time. Again, crap happens... offhand, this is the first horkage I've ever seen the dev in question make that was user visible borkage of the cache- one mistake in 11 months ain't bad :)
