I recently stepped on packages with conflicting dependencies in the tree. Explicitly that are the breakmygentoo-ebuilds gnutls/opencdk/libgcrypt. The problem is this: gnutls-1.0.4 DEPENDs on opencdk-0.5.3 and >=libgcrypt-1.1.90 (no further RDEPENDs) opencdk-0.5.3 RDEPENDs on =libgcrypt-1.1.43-r1 If you watch closely this is a bit contradicting. Anyway now for the portage related part: If you emerge gnutls, it will emerge: [ebuild N ] dev-libs/libgcrypt-1.1.91 [ebuild N ] dev-libs/libgcrypt-1.1.43-r1 [ebuild N ] app-crypt/opencdk-0.5.3 [ebuild N ] net-libs/gnutls-1.0.4 (yes in THAT order) Anyway, if you have that emerged and do a --deep --update world later, it will emerge libgcrypt-1.1.91. If you do another deep update later it will emerge libgcrypt-1.1.43-r1 again and so on. My point is that there are obviously some conflicting RDEPENDS (as RDEPEND=DEPEND in gnutls) which portage doesn't recognize and much worse it always tries to resolve one RDEPEND in favor of the other. I think portage should either show consistent behaviour or even better should spit out a warning or error about conflicting dependencies. NB: even --upgradeonly doesn't stop emerge from downgrading Reproducible: Always Steps to Reproduce: I'll attach a little test case which reproduces the problem. It conatins four dummy packages app-admin/rdepend-test-* (* in a, b, c) The deps are: a-1: DEPENDs on b-1 and >=c-1.1 b-1: RDEPENDs on =c-1.0 1. untarbz the attached testcase into your local portage 2. emerge rdepend-test-a 3. emerge --deep --update rdepend-test-a 4. emerge --deep --update rdepend-test-a 5. emerge --deep --update rdepend-test-a ... (you may use --updateonly in steps 3 to 5, too, it doesn't change anything) Actual Results: 2. emerges (in that order) rdepend-test-c-1.0 rdepend-test-b-1 rdepend-test-c-1.1 (unmerges c-1.0 here) rdepend-test-a-1 3. emerges rdepend-test-c-1.0 (unmerges c-1.1 here) 4. emerges rdepend-test-c-1.1 (unmerges c-1.0 here) 5. emerges rdepend-test-c-1.0 (unmerges c-1.1 here) ... Expected Results: I think portage should report an error because of conflicting runtime dependencies. Consistent behaviour would be a start but could lead to hidden package breaking.
Created attachment 26391 [details] Bunch of test case ebuilds
almost forgot... triphoenix@triphoenix root $ emerge info Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.1) ================================================================= System uname: 2.6.1 i686 AMD Athlon(tm) XP 2100+ Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /etc/tomcat /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /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/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache nostrip sandbox userpriv" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X aalib acl alsa apache2 apm arts avi berkdb bonobo cdr crypt cups dedicated dvd dvdr encode esd fbcon foomaticdb gd gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib java jpeg kde libg++ libwww mad mikmod mmx motif mozilla moznocompose mpeg mysql nas ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang spell sse ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
i think the better 'fix' is to change the ebuild if you're going to DEPEND on a specific version, that version better be SLOT-ed
Sure the ebuidl needs a fix, too. Nevertheless, this is a bug in portage because it should report the inconsistency.
that depends on the performance hit of the implementation ... if it's too significant, then it probably shouldnt be done fix the ebuilds and theres no problem
Valid argument. But then I'd say that a) portage still should show consequent behaviour, e.g. at least stay at the newer package or something b) if the performance impact is there, perhaps some sort of switch like --validate or something should be there, because if you stumble upon such ebuild it can be really annoying to find the error :) Perhaps could be implemented as external tool, I'll think about that :)
*** This bug has been marked as a duplicate of 13632 ***
