there is an conflict with libav Reproducible: Always
Calculating dependencies... done! [ebuild N ] dev-java/pdfbox-0.7.3-r2::lokal USE="-doc -source" 0 kB [ebuild N ] dev-tex/pdfannotextractor-0.1l 0 kB [ebuild N ] app-text/texlive-2013 USE="X cjk context detex dvi2tty dvipdfm extra games graphics humanities jadetex luatex music omega pdfannotextractor png pstricks publishers science tex4ht truetype xetex xindy xml -epspdf -metapost -texi2html" LINGUAS="de en vi -af -ar -as -bg -bn -br -ca -cs -cy -da -el -en_GB -eo -es -et -eu -fa -fi -fr -ga -gl -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -kn -ko -la -lo -lt -lv -ml -mn -mr -nb -nl -nn -no -or -pa -pl -pt -rm -ro -ru -sa_IN -sco -sk -sl -sq -sr -sv -ta -te -th -tk -tr -uk -zh" 0 kB [ebuild NS ] media-video/ffmpeg-1.2.2:0 [0.10.8:0.10] USE="X aac alsa bzip2 encode gnutls hardcoded-tables iconv jack jpeg2k mmx mp3 oss pulseaudio sdl ssse3 truetype vorbis x264 xvid zlib -3dnow -3dnowext -aacplus (-altivec) -amr -avx -bindist -bluray -cdio (-celt) -cpudetection -debug -doc -examples -faac -fdk -flite -fontconfig -frei0r -gsm -iec61883 -ieee1394 -libass -libcaca -libsoxr -libv4l -mmxext -modplug (-neon) -network -openal -openssl -opus -pic -rtmp -schroedinger -speex -static-libs {-test} -theora -threads -twolame -v4l -vaapi -vdpau (-vis) -vpx" FFTOOLS="aviocat cws2fws ffescape ffeval fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart trasher" 5,829 kB [uninstall ] media-libs/libpostproc-0.8.0.20121125 USE="mmx -3dnow (-altivec) -mmxext -pic -static-libs" [blocks b ] media-video/ffmpeg:0 ("media-video/ffmpeg:0" is blocking media-libs/libpostproc-0.8.0.20121125) [blocks b ] media-libs/libpostproc ("media-libs/libpostproc" is blocking media-video/ffmpeg-1.2.2) [blocks B ] media-video/ffmpeg:0 ("media-video/ffmpeg:0" is blocking media-video/libav-9.8) Total: 4 packages (3 new, 1 in new slot, 1 uninstall), Size of downloads: 5,829 kB Conflict: 3 blocks (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (media-video/libav-9.8::gentoo, installed) pulled in by >=media-video/libav-9[X?,encode?,gsm?,jpeg2k?,mp3?,opus?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?] (>=media-video/libav-9[X,encode,jpeg2k,mp3,sdl,threads,truetype,vdpau,x264]) required by (virtual/ffmpeg-9::gentoo, installed) (media-video/ffmpeg-1.2.2::gentoo, ebuild scheduled for merge) pulled in by media-video/ffmpeg:0 required by (media-video/mplayer2-2.0_p20130428-r1::gentoo, installed) media-video/ffmpeg:0 required by (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r1::gentoo, installed) For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
Your output doesn't list any app-emulation/emul-* packages. It looks like a conflict between media-video/libav and media-video/ffmpeg, so why does the Summary mention emul?
the problem is i am using smplayer2 and vlc, both ask for libav. it install there for also: virtual/ffmpeg-9. unfortunatelly app-emulation/emul-linux-x86-medialibs-20130224-r12 required media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r1 and it cause a conflict, because it need media-video/ffmpeg-1.2.2. whats the solution in this case? can we have a USE ffmpeg or libab for smplayer2, mplayer2, vlc... and let other packages depends all on virtual/ffmpeg ? would this solve the conflict? [ebuild U ] media-plugins/caps-plugins-0.9.10 [0.4.5-r2] USE="-doc%" ABI_X86="32 (64) (-x32)" 668 kB [ebuild U ] dev-python/sip-4.15_pre20130814:0/10::qt [4.15_pre20130808:0/10::qt] USE="-debug -doc" PYTHON_TARGETS="python2_7 python3_2 -python2_6 -python3_3" 731 kB [ebuild U ] net-print/cups-filters-1.0.36 [1.0.35-r1] USE="jpeg perl png tiff -static-libs -zeroconf" 1,009 kB [ebuild U ] media-plugins/frei0r-plugins-1.4 [1.3] USE="facedetect scale0tilt -doc" 1,138 kB [ebuild NS ] media-video/ffmpeg-1.2.2:0 [0.10.8:0.10] USE="X aac alsa bzip2 encode gnutls hardcoded-tables iconv jack jpeg2k mmx mp3 oss pulseaudio sdl ssse3 truetype vorbis x264 xvid zlib -3dnow -3dnowext -aacplus (-altivec) -amr -avx -bindist -bluray -cdio (-celt) -cpudetection -debug -doc -examples -faac -fdk -flite -fontconfig -frei0r -gsm -iec61883 -ieee1394 -libass -libcaca -libsoxr -libv4l -mmxext -modplug (-neon) -network -openal -openssl -opus -pic -rtmp -schroedinger -speex -static-libs {-test} -theora -threads -twolame -v4l -vaapi -vdpau (-vis) -vpx" FFTOOLS="aviocat cws2fws ffescape ffeval fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart trasher" 5,829 kB [uninstall ] media-libs/libpostproc-0.8.0.20121125 USE="mmx -3dnow (-altivec) -mmxext -pic -static-libs" [blocks b ] media-video/ffmpeg:0 ("media-video/ffmpeg:0" is blocking media-libs/libpostproc-0.8.0.20121125) [blocks b ] media-libs/libpostproc ("media-libs/libpostproc" is blocking media-video/ffmpeg-1.2.2) [blocks B ] media-video/ffmpeg:0 ("media-video/ffmpeg:0" is blocking media-video/libav-9.8) Total: 5 packages (4 upgrades, 1 in new slot, 1 uninstall), Size of downloads: 9,372 kB Conflict: 3 blocks (1 unsatisfied) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (media-video/libav-9.8::gentoo, installed) pulled in by >=media-video/libav-9[X?,encode?,gsm?,jpeg2k?,mp3?,opus?,sdl?,speex?,theora?,threads?,truetype?,vaapi?,vdpau?,x264?] (>=media-video/libav-9[X,encode,jpeg2k,mp3,sdl,threads,truetype,vdpau,x264]) required by (virtual/ffmpeg-9::gentoo, installed) ( ::gentoo, ebuild scheduled for merge) pulled in by media-video/ffmpeg:0 required by (media-video/mplayer2-2.0_p20130428-r1::gentoo, installed) media-video/ffmpeg:0 required by (media-video/vlc-2.0.7::gentoo, installed) media-video/ffmpeg:0 required by (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r1::gentoo, installed) For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
On my system update, the update from app-emulation/emul-linux-x86-medialibs-20130224-r11 to app-emulation/emul-linux-x86-medialibs-20130224-r12 pulled in media-video/ffmpeg-0.10.8, as a new dependency, as per the changelog; http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/emul-linux-x86-medialibs/ChangeLog This was done on my system which has libav and postproc installed. On the next system update, my system wanted to upgrade to the latest media-video/ffmpeg-1.2.2, and it's then that when all the ffmpeg/libav blocking conflict appeared, as in the bug report. I'm worked around this issue by putting app-emulation/emul-linux-x86-medialibs-20130224-r11.ebuild in my local overlay and forcing the downgrade, and then masking app-emulation/emul-linux-x86-medialibs-20130224-r12. The question is, will app-emulation/emul-linux-x86-medialibs-20130224 be updated to work with media-video/libav as well?
finally a confirmation of my problem. my emerge -uDN world stuck now because this problem of: app-emulation/emul-linux-x86-medialibs-20130224-r12 and libav and ffmpeg. i hope some dev could solve this as soon as possible.
I guess we need to get libav supporting multilib too
I specifically made sure ffmpeg:0.10 could be installed in parallel with both libav-9 and ffmpeg-1.2 so I don't think the problem is with emul-* This was made because the current bundled ffmpeg version in emul-* is a security hazard; ffmpeg 0.10.8, while not perfect, is much better and ABI compatible. The real solution is of course to convert libav and ffmpeg:0 and all its rev. deps to multilib but this will take much more time; look at usemasks for ffmpeg-0.10 in base/package.use.mask and then the reverse dependencies need to be rebuilt since the abi changed.
can u please explain exactly the work around for the moment?
I don't know try to rebuild: media-video/mplayer2-2.0_p20130428-r1, media-video/vlc-2.0.7 and media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r1 those certainly don't need ffmpeg:0 and work with libav, contrary to what portage suggests
I think portage simply tries to be smart and, well, upgrade ffmpeg :P.
Alternatively, you could have one package with ffmpeg-only dep and some others with || deps. Then, portage will those || along with ffmpeg-only. That's why || deps suck and we need a good virtual/ffmpeg instead.
(In reply to Michał Górny from comment #11) > Alternatively, you could have one package with ffmpeg-only dep and some > others with || deps. See my comment. Those that pull ffmpeg shouldn't. > Then, portage will those || along with ffmpeg-only. > That's why || deps suck and we need a good virtual/ffmpeg instead. any kind of virtual will not help with this; you have the same with virtual/jpeg and firefox[system-jpeg]. I don't follow your reasoning on || deps, a virtual is just a (useless) level of indirection for a ||. a simplification in most cases, but for some packages, considering the divergence between ffmpeg and libav, its just not worth it now.
The indirection makes it helpful. If you have 20 packages using the virtual, and 1 using ffmpeg directly, portage will tell that ffmpeg is pulled in by the one package + virtual. if you have 20 packages using || and 1 using ffmpeg directly, portage will tell you that ffmpeg is pulled by all (most) of them. Enjoy reading the deps then.
(In reply to Michał Górny from comment #13) > The indirection makes it helpful. > > If you have 20 packages using the virtual, and 1 using ffmpeg directly, > portage will tell that ffmpeg is pulled in by the one package + virtual. > > if you have 20 packages using || and 1 using ffmpeg directly, portage will > tell you that ffmpeg is pulled by all (most) of them. Enjoy reading the deps > then. comment #1 and comment #3 are not like that it seems; and in any case, this just sounds like a portage limitation than anything else.
(In reply to tman from comment #8) > can u please explain exactly the work around for the moment? Try masking ffmpeg:0 like this: echo media-video/ffmpeg:0 >> /etc/portage/package.mask Also, verify that media-libs/libpostproc is not masked: emerge -pv media-libs/libpostproc
JFYI: comment #15 seems to work here.
thanks a lot. until a official solution come it should be a work around :)
(In reply to Michał Górny from comment #10) > I think portage simply tries to be smart and, well, upgrade ffmpeg :P. That could be the case if there's anything that has a media-video/ffmpeg dependency which is currently satisfied by the media-video/ffmpeg:0.10 slot but could also be satisfied by the media-video/ffmpeg:0 slot. If that "upgrade" causes media-video/ffmpeg:0 to get pulled into the graph, then it can affect the dependency choices for || ( media-libs/libpostproc media-video/ffmpeg:0 ) deps from other packages, causing them to choose the media-video/ffmpeg:0 instead of media-libs/libpostproc because media-video/ffmpeg:0 happens to be in the graph already.
(In reply to Zac Medico from comment #18) > (In reply to Michał Górny from comment #10) > > I think portage simply tries to be smart and, well, upgrade ffmpeg :P. > > That could be the case if there's anything that has a media-video/ffmpeg > dependency which is currently satisfied by the media-video/ffmpeg:0.10 slot > but could also be satisfied by the media-video/ffmpeg:0 slot. If that > "upgrade" causes media-video/ffmpeg:0 to get pulled into the graph, then it > can affect the dependency choices for || ( media-libs/libpostproc > media-video/ffmpeg:0 ) deps from other packages, causing them to choose the > media-video/ffmpeg:0 instead of media-libs/libpostproc because > media-video/ffmpeg:0 happens to be in the graph already. That's weird. I changed all rev deps to ffmpeg:0 before committing this, but then maybe portage was using vdb which did have the :0 ?
(In reply to Alexis Ballier from comment #19) > That's weird. I changed all rev deps to ffmpeg:0 before committing this, but > then maybe portage was using vdb which did have the :0 ? No, I think all is well there. However, I have no idea why ffmpeg:0 got pulled in. If someone can produce a debug log that reproduces the problem, then it may give us a clue as to how ffmpeg:0 initially got pulled in: emerge [args] --debug > debug.log 2>&1 xz -9 debug.log
Created attachment 356254 [details] portage debug log portage debug log as requested in comment #20.
(In reply to Lukas Schneiderbauer from comment #21) > Created attachment 356254 [details] > portage debug log Does it make any difference if you rebuild media-libs/libpostproc? emerge --oneshot media-libs/libpostproc The first sign of trouble is right here where it selects Candidates: ['media-video/ffmpeg:0'] for some reason: Parent: (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r1::gentoo, installed) Depstring: || ( media-video/ffmpeg:0 media-libs/libpostproc ) Priority: runtime ebuild: media-libs/libpostproc-0.8.0.20121125::gentoo installed: media-libs/libpostproc-0.8.0.20121125::gentoo ebuild: media-libs/libpostproc-0.8.0.20121125::gentoo installed: media-libs/libpostproc-0.8.0.20121125::gentoo Candidates: ['media-video/ffmpeg:0'] ebuild: media-video/ffmpeg-1.2.2::gentoo
Created attachment 356256 [details] portage debug log after rebuilding media-libs/libpostproc (In reply to Zac Medico from comment #22) > Does it make any difference if you rebuild media-libs/libpostproc? > > emerge --oneshot media-libs/libpostproc > I cannot see any. Just in case I added the portage debug log which was generated after rebuilding media-libs/libpostproc.
(In reply to Lukas Schneiderbauer from comment #23) > Created attachment 356256 [details] > portage debug log after rebuilding media-libs/libpostproc > > (In reply to Zac Medico from comment #22) > > Does it make any difference if you rebuild media-libs/libpostproc? > > > > emerge --oneshot media-libs/libpostproc > > > I cannot see any. > Just in case I added the portage debug log which was generated after > rebuilding media-libs/libpostproc. Yeah it still has the same problem starting here: Parent: (media-plugins/gst-plugins-ffmpeg-0.10.13_p201211-r1::gentoo, installed) Depstring: || ( media-video/ffmpeg:0 media-libs/libpostproc )
I think this is what causes it: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=94130821ab21186aeca7c514236a60acf6a71082
I'm not sure if there's a good way to separate the || ( libpostproc ffmpeg:0 ) case from the || ( vala:0.20 vala:0.18 ) case in bug #478188. If we have to choose between fixing one or the other, maybe bug #478188 should take precedence because it seems like it might be a slightly more common case.
(In reply to Zac Medico from comment #26) > I'm not sure if there's a good way to separate the || ( libpostproc ffmpeg:0 > ) case from the || ( vala:0.20 vala:0.18 ) case in bug #478188. > > If we have to choose between fixing one or the other, maybe bug #478188 > should take precedence because it seems like it might be a slightly more > common case. it'd be much better if there was no choice to make: - the vala case is indeed much more common - this precise case is supposed to be temporary, but I would expect it to be around for a couple of months at least - the vala case can be solved by manually updraging vala - this case will always ask you to install ffmpeg unless you mask it one idea: the || ( libpostproc ffmpeg:0 ) dep is, strictly speaking, wrong since it needs the indirect dependencies of libpostproc. would: || ( ( libav libpostproc ) ffmpeg:0 ) help portage ? in this case, it is clear that no branch is an update of another one. Or maybe, just making libpostproc depend on libav instead of virtual/ffmpeg.
(In reply to Alexis Ballier from comment #27) > would: || ( ( libav libpostproc ) ffmpeg:0 ) help portage ? in this case, it > is clear that no branch is an update of another one. The current logic is such that portage will still see the ffmpeg:0 branch as an upgrade relative to ffmpeg:0.10. So your suggested change won't help. > Or maybe, just making libpostproc depend on libav instead of virtual/ffmpeg. That won't help either. One thing that would help would be to put libpostproc on the left. As you can see in the debug output posted in comment #22, in the media-plugins/gst-plugins-ffmpeg deps, libpostproc is on the right and ffmpeg:0 is on the left. If that order were swapped, then portage would prefer libpostproc.
(In reply to Zac Medico from comment #28) > One thing that would help would be to put libpostproc on the left. As you > can see in the debug output posted in comment #22, in the > media-plugins/gst-plugins-ffmpeg deps, libpostproc is on the right and > ffmpeg:0 is on the left. If that order were swapped, then portage would > prefer libpostproc. for gst-ffmpeg I think it makes more sense to have libav/libpostproc first since that's what upstream is using; feel free to change it, but that won't solve entirely the problem since there are others for which it doesnt make sense to have it first.
I should be able to tweak the ordering logic so that it prefers libpostproc due to it being installed already. It is distinguishable from the || ( vala:0.20 vala:0.18 ) case because there's no ${CATEGORY}/${PN} intersection between the || ( ffmpeg:0 libpostproc ) choices.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c08402d745eef26b99091f62556f48aa9b60345a
This is fixed in 2.2.1.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=097cf78c22b3d523f701ab36f47714c604690b23 commit 097cf78c22b3d523f701ab36f47714c604690b23 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-01-26 06:20:17 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-26 06:27:00 +0000 OrChoicesTestCase: split out bug 480736 libpostproc test case This case will become an expected failure after bug 706278 is fixed. The packages that triggered bug 480736 not longer exist. Bug: https://bugs.gentoo.org/480736 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/tests/resolver/test_or_choices.py | 115 +++++++++++++------------- 1 file changed, 59 insertions(+), 56 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=f7d83d75c6b05a16ef07473917082dbd0cd9955c commit f7d83d75c6b05a16ef07473917082dbd0cd9955c Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-01-26 01:44:14 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-27 03:18:02 +0000 dep_zapdeps: adjust || preference for slot upgrades (bug 706278) Prefer choices that include a slot upgrade when appropriate, like for the || ( llvm:10 ... llvm:7 ) case reported in bug 706278. In order to avoid pulling in inappropriate slot upgrades, like those which should only be pulled in with --update and --deep, add a want_update flag to each choice which is True for choices that pull in a new slot for which an update is desirable. Mark the test case for bug 480736 as todo, since the "undesirable" slot upgrade which triggers a blocker conflict in this test case is practically indistinguishable from a desirable slot upgrade. This particular blocker conflict is no longer relevant, since current versions of media-libs/libpostproc are no longer compatible with any available media-video/ffmpeg slot. In order to solve this test case, some fancy backtracking (like for bug 382421) will be required. Bug: https://bugs.gentoo.org/706278 Bug: https://bugs.gentoo.org/480736 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/_emerge/depgraph.py | 16 ++++- lib/portage/dep/dep_check.py | 79 ++++++++++++---------- lib/portage/tests/resolver/test_or_choices.py | 9 +++ .../tests/resolver/test_or_upgrade_installed.py | 3 +- 4 files changed, 67 insertions(+), 40 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34b349600f178ed252c125866c3c3fd731cfb2f4 commit 34b349600f178ed252c125866c3c3fd731cfb2f4 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-01-28 05:18:53 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-01-28 05:19:09 +0000 sys-apps/portage: Bump to version 2.3.86 #706278 Adjust || preference for slot upgrades #706298 Suppress package.keywords warning for API consumers Bug: https://bugs.gentoo.org/706142 Bug: https://bugs.gentoo.org/480736 Bug: https://bugs.gentoo.org/706278 Bug: https://bugs.gentoo.org/706298 Package-Manager: Portage-2.3.86, Repoman-2.3.20 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.86.ebuild | 276 +++++++++++++++++++++++++++++++++ 2 files changed, 277 insertions(+)
