When a package is split (such as faad2 into faad2 and libmp4v2) portage is unable to handle the upgrade. It says that the old package conflicts with the new split-off package. It does not see that the conflict can be resolved by upgrading the package to the current version (which is requested anyway, and it is the reason why the split-off package was pulled in in the first place). generally, portage does not detect that after its job is finished there would be no conflicts. It arranges the packages in some order, and if there would be a conflict in some intermediate state it refuses to perform the merge. The workaround is to manually remove the offending package (in this case I remove faad2 wich allows to merge libmp4v2 on which the new faad2 depends). Portage 2.1_pre10-r2 (hardened/x86/2.6, gcc-3.4.5, glibc-2.3.6-r3, 2.6.15-gentoo-r4 i686) ================================================================= System uname: 2.6.15-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.12.0 dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /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/" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks maketest metadata-transfer nostrip sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.sh.cvut.cz/MIRRORS/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage//packages/x86/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac accessibility aim alsa apache2 berkdb bzip2 canna crypt cups debug dga dlloader dmx doc dri dts dvd examples fbcon ffmpeg flac foomaticdb fpx gif gimpprint glitz glut gnutls gpm gs gtk hardened icq icu ipv6 irc jabber java jbig jpeg kerberos krb4 lcms ldap libclamav matroska mmx mng mono mozilla mp3 mpeg msn nas ncurses nls nptl nptlonly nsplugin offensive ogg opengl pam pic png ppds readline samba sasl speex spell sse ssl svg tcpd theora threads tiff truetype truetype-fonts unicode userlocales vcd vorbis win32codecs wmf x86 xml xml2 xosd xv zlib elibc_glibc input_devices_evdev input_devices_mouse input_devices_keyboard input_devices_kbd input_devices_joystick kernel_linux userland_GNU video_cards_mga video_cards_radeon video_cards_ati" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
*** This bug has been marked as a duplicate of 79606 ***
I'm not sure if this is a duplicate. In the other bug the problem is the order in which the packages are merged. Here the problem can be solved only by uninstalling a package because portage does not know something like replacing packages. In debian, libmp4v2 would replace (faad2 << someversion) so that the mp4v2 libraries in faad2 are replaced with those in libmp4v2, and are then owned by libmp4v2. faad2 would still own the other libraries, and they would get updaed when the new faad2 is installed.
it is a dupe, as the other bug is basically a 'portage sucks at blocker handling'. it's really just different effects of the same underlying problem.
(In reply to comment #3) > it is a dupe, as the other bug is basically a 'portage sucks at blocker > handling'. it's really just different effects of the same underlying problem. > the underlying problem being that the dependency resolver code should be smart enough to realize there is a simple workaround to the blockers. However the present resolver is rather dumb in this regard, and you get behavior such as this.
