I have two machines where I am taking advantage of the -k parameter on emerge. But right now, when I am trying "emerge -uDpvk world" with the following results: These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] dev-php/PEAR-XML_RPC-1.4.3 [1.4.2] 0 kB [binary UD] x11-libs/qt-3.3.4-r3 [3.3.4-r8] +cups -debug -doc -examples -firebird +gif -immqt -immqt-bc -ipv6 -mysql* -nas -odbc +opengl -postgres* -sqlite +xinerama +zlib Total size of downloads: 0 kB See that qt is being downgraded to 3.3.4-r3? Why? If I try "emerge -uDpv world" I get the expected results: katsuhiro rodrigo # emerge -uDpv world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] dev-php/PEAR-XML_RPC-1.4.3 [1.4.2] 0 kB Total size of downloads: 0 kB No messing with qt as it's already upgraded. The behaviour of "emerge -uDpvk world" is buggy, isn't it? Reproducible: Always Steps to Reproduce: katsuhiro rodrigo # emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r1, 2.6.11-win4lin i686) ================================================================= System uname: 2.6.11-win4lin i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] 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=i686 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=i686 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distcc distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.ccccom.com http://gentoo.mirror.sdv.fr http://distro.ibiblio.org/pub/Linux/distributions/gentoo/ http://gentoo.mirrors.pair.com/ http://gentoo.osuosl.org/" LANG="pt_BR" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-fabrica" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac aalib alsa apm arts audiofile avi bitmap-fonts bzip2 bzlib cddb cdparanoia cdr crypt cups curl dga dts dvd edl eds emboss encode faac faad fam fame ffmpeg flac foomaticdb fortran gd gdbm gif gimpprint gmp gpm gstreamer gtk2 imagemagick imlib jbig jpeg jpeg2k kde kdeenablefinal lcms ldap libcaca libg++ libwww live lzo mad matroska md5sum mikmod mjpeg mng motif mp3 mpeg mysql ncurses nls ogg oggvorbis opengl oss pam pdflib perl png postgres ppds python qt quicktime readline real ruby samba scanner sdl speex spell ssl svg svga tcpd tga theora tiff truetype truetype-fonts type1-fonts unicode vcd vorbis win32codecs wmf xine xinerama xml2 xmms xv xvid xvmc zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, LINGUAS
I'm going to mark this one as INVALID in advance, because I'm sure it's behaving correctly. If emerge --tree -uDpvk doesn't show you why, add --debug and add that as an attachment and I'll tell you why.
Man, I have already bugs marked INVALID but definitely none as fast as this one :) emerge -uDavkt world gives me (just the relevant portion): [nomerge ] kde-base/kdeaddons-meta-3.4.1 +arts [nomerge ] kde-base/noatun-plugins-3.4.1 +arts -berkdb -debug +kdeenablefinal -kdexdeltas +sdl +xinerama [nomerge ] kde-base/noatun-3.4.1 +arts +audiofile -debug +kdeenablefinal -kdexdeltas +xine +xinerama [nomerge ] kde-base/kdelibs-3.4.1-r1 +alsa +arts +cups -debug -doc +jpeg2k +kdeenablefinal -kerberos -openexr +spell +ssl +tiff +xinerama -zeroconf [binary UD] x11-libs/qt-3.3.4-r3 [3.3.4-r8] +cups -debug -doc -examples -firebird +gif -immqt -immqt-bc -ipv6 -mysql* -nas -odbc +opengl -postgres* -sqlite +xinerama +zlib emerge -uDavt world gives no qt messing at all. I looked at the debug output and I believe I understood why is this happening but it still looks as an unwanted feature (= bug): why with -k I get a downgrade and without -k I don't. Just to be clear, I would understand if this kind of thing happened with -K but with -k? Anyway I am attaching the debug output of "emerge --tree --debug -uDpvk world" and of "emerge --tree --debug -uDpv world". Is this really the intended behaviour?
Created attachment 69553 [details] "emerge --tree --debug -uDpvk world" log
Created attachment 69554 [details] "emerge --tree --debug -uDpv world" log I compressed this one as the file is too big.
Yep, as you've probably already noted the binary package you have of kdelibs-3.4.1-r1 effectively DEPENDs on >=qt-3.3.3 <=qt-3.3.4-r7 and the closest binary you have to that is qt-3.3.4-r3. Thus portage chooses that one and continues on its way. Whether ignoring what the installed package DEPENDs on is preferable is debateable (and pretty one sided at that ;) but the deficiencies of the resolver in portage-2.0.x have been accepted. This bug is in the domain of what is considered an unfixable deficiency. This and other fundamental flaws will be resolved in an upcoming rewrite. Perhaps I should have marked it CANTFIX or WONTFIX?
Please don't change it from RESOLVED INVALID as you would ruin a new personal record :) Seriously INVALID X [WONTFIX|CANTFIX] isn't much of an issue here but thanks for asking anyway. I don't think ignoring what the packages DEPENDs on is a good solution at all. I see that the dependency is defined in the ebuild as "$(qt_min_version 3.3.3)" and in the "emerge --debug" file as a fixed list of allowed versions. Just to be sure I understood the issue correctly, the depencencies are recorded after intallation in a different file, i.e., the .ebuild file isn't used anymore AND the dependencies aren't recorded in the same format they are defined in the .ebuild file: in a less adaptative format. Please consider this a request to extend the more adaptative format of dependency recording to the relevant files after installation in future portage versions. This seems as a perfect solution for issues like these, besides eventual implementaions problems I might be unaware of. Thanks for your help, time and attention explaining me the finer issues of portage management. And please leave this bug as RESOLVED INVALID!
