It seems like there is some bug in the version checking logic when using the -u flag. /usr/portage $ qpkg -v -I erlang dev-lang/erlang-9c * /usr/portage $ emerge -p media-libs/esdl/esdl-0.93.0314.ebuild These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] media-libs/esdl-0.93.0314 /usr/portage $ emerge -up media-libs/esdl/esdl-0.93.0314.ebuild These are the packages that I would merge, in order: Calculating dependencies | !!! all ebuilds that could satisfy ">=dev-lang/erlang-9b" have been masked. !!! (dependency required by "media-libs/esdl-0.93.0314" [ebuild]) !!! Error calculating dependencies. Please correct. Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.48 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.20-gentoo-r5 i686 Celeron (Mendocino) GENTOO_MIRRORS="http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://ftp. belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp://ftp.belnet.be/mirror/rsync. gentoo.org/gentoo/ http://ftp.gentoo.or.kr/ http://ftp.snt.utwente. nl/pub/os/linux/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /var/bind /usr/X11R6/lib/X11/xkb /usr/kde/3. 1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/local/download/portage/distfiles" PKGDIR="/usr/local/download/portage/packages-pentium2" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/download/portage" USE="x86 oss apm avi crypt cups encode gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib directfb gtkhtml alsa gdbm berkdb slang readline arts tetex aalib nas bonobo svga ggi tcltk java guile mysql postgres X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla gphoto2 snmp cdr scanner acl acpi atlas curl dga doc dvb dvd emacs ethereal evo fbcon flash gb gd gnomedb gps gtk2 imap innodb ipv6 jikes junit kerberos lcms ldam leim libgda mbox mozaccess mozcalendar mozinterfaceinfo mozsvg mozxmlterm mpi mule objc odbc pcmcia pda pic plotutils pnp ruby samba sasl slp socks5 tiff trusted usb wmf Xaw3d xinerama xml -3dnow" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -mcpu=pentium2 -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-jumps=4 -falign-loops=4" CXXFLAGS="-march=pentium2 -mcpu=pentium2 -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-jumps=4 -falign-loops=4" ACCEPT_KEYWORDS="x86 jer" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="ccache sandbox buildpkg userpriv usersandbox"
george: can you plz check dependency
Hm, not sure how esdl-0.93.0314 got into stable with previous version still in testing. I don't remember changing the KEYWORDS when committing that fix, but must have been me :(. I moved both erlang-9b and 9c to stable. I got recently test reports on 9c but wanted to give it a bit more time to get tested out. This would be a nice occasion. 9b should have been unmasked quite some time ago, but test reports on it were emailed to me instead of being attached to the bug :(. Anyway, this should be resolved now. George
The bug isn't the stability flags in the packages but a bug with 'emerge' itself. Why is -u causing the installation to fail because of a lacking dependeny (which is installed) whereas without '-u', the the installation would go ahead.
is this happening just because of the erlang ebuild versions are screwing up portage... perhaps naming the erlang ebuilds something different can clean this up... 9a -> 9.0.0 9b -> 9.0.1 9c -> 9.0.2 Also, there's not metadata.xml in the erlang directory...
ACCEPT_KEYWORDS="x86 jer" wtf is jer ? and i dont see why we should change the versions to be .0 .1 .2 when in reality portage should know that .c is newer than .b newer than .a
does portage know that c is newer than b? Then why was it saying that '>=dev-lang/erlang-9b' couldn't be satisfied when erlang-9c was stable...
versions work as expected, the -u behavior is more a documentation error (side-effect of updating dependencies).
