# stable vlc will unstable libav

## schmidicom

Kann mir mal einer erklären warum der bereits installierte stable VLC nach einem portage-sync auf einmal ein unstable libav verlangt?

```
These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild     U  ] sys-devel/binutils-config-4-r2::gentoo [3-r3::gentoo] 0 KiB

[ebuild     U ~] sys-apps/microcode-ctl-1.28::gentoo [1.27::gentoo] USE="(-selinux)" 857 KiB

[ebuild     U  ] dev-db/sqlite-3.8.9:3::gentoo [3.8.7.4:3::gentoo] USE="icu readline -debug -doc -secure-delete -static-libs -tcl {-test}" ABI_X86="(64) -32 (-x32)" 1.990 KiB

[ebuild     U  ] dev-util/dialog-1.2.20150225::gentoo [1.2.20140911::gentoo] USE="nls unicode -examples -minimal -static-libs" 463 KiB

[ebuild     U  ] dev-libs/libxml2-2.9.2-r1:2::gentoo [2.9.2:2::gentoo] USE="icu ipv6 lzma python readline -debug -examples -static-libs {-test}" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 0 KiB

[ebuild     U  ] sys-apps/kmod-20::gentoo [19::gentoo] USE="lzma python tools zlib -debug -doc -static-libs" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 428 KiB

[ebuild    FU  ] dev-java/oracle-jdk-bin-1.8.0.45:1.8::gentoo [1.8.0.40-r1:1.8::gentoo] USE="X alsa derby fontconfig jce nsplugin (-aqua) -doc -examples -pax_kernel (-selinux) -source" 169.211 KiB

[ebuild     U  ] sys-apps/iproute2-3.19.0::gentoo [3.17.0::gentoo] USE="atm berkdb iptables ipv6 -minimal (-selinux)" 445 KiB

[ebuild     U  ] app-crypt/xca-1.1.0::gentoo [0.9.3-r1::gentoo] USE="-bindist (-doc%)" 835 KiB

[ebuild     U  ] net-wireless/wpa_supplicant-2.4-r1::gentoo [2.2-r1::gentoo] USE="dbus gnutls hs2-0%* qt4 readline ssl -ap -eap-sim -fasteap -p2p (-ps3) (-selinux) -smartcard -tdls% -uncommon-eap-types% -wimax -wps" 2.467 KiB

[ebuild     U ~] sys-apps/hwids-20150421::gentoo [20150129::gentoo] USE="net pci udev usb" 1.687 KiB

[ebuild     U  ] sys-apps/man-pages-3.82::gentoo [3.81::gentoo] USE="nls" LINGUAS="de -da -fr -it -ja -nl -pl -ro -ru -zh_CN" 1.326 KiB

[ebuild     U  ] net-misc/curl-7.42.0::gentoo [7.39.0::gentoo] USE="idn ipv6 kerberos ldap rtmp samba%* ssl threads -adns -metalink -ssh -static-libs {-test}" ABI_X86="(64) -32 (-x32)" CURL_SSL="gnutls -axtls -nss -openssl -polarssl (-winssl)" 3.253 KiB

[ebuild     U ~] sys-apps/systemd-219_p112:0/2::gentoo [219-r2:0/2::gentoo] USE="acl audit cryptsetup curl gcrypt gudev http idn introspection kdbus kmod lz4 lzma pam (policykit) python qrcode seccomp ssl sysv-utils xkb -apparmor -doc -elfutils -importd -nat (-selinux) -terminal {-test} -vanilla" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 3.853 KiB

[ebuild     U  ] net-print/cups-2.0.2-r1::gentoo [2.0.1-r1::gentoo] USE="X acl dbus java kerberos pam python ssl systemd threads usb zeroconf -debug -lprng-compat (-selinux) -static-libs -xinetd" ABI_X86="(64) -32 (-x32)" LINGUAS="de%* -ca% -cs% -es -fr% -it% -ja% -pt_BR% -ru%" PYTHON_TARGETS="python2_7" 8.562 KiB

[ebuild     U  ] dev-python/reportlab-3.1.44-r1::gentoo [3.1.8-r2::gentoo] USE="-doc -examples" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 1.901 KiB

[ebuild     U ~] media-libs/mesa-10.5.4::gentoo [10.5.2::gentoo] USE="classic d3d9 dri3 egl gallium gbm gles1 gles2 llvm nptl opencl openmax osmesa udev vaapi vdpau wayland xa xvmc -bindist -debug -pax_kernel -pic (-selinux)" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="r100 r200 r300 r600 radeon radeonsi (-freedreno) -i915 -i965 -ilo -intel -nouveau -vmware" 6.825 KiB

[ebuild   R   ~] dev-qt/qtgui-5.4.1-r1:5::gentoo  USE="accessibility egl eglfs evdev gif gles2 harfbuzz ibus jpeg kms opengl png udev xcb -debug -gtkstyle% {-test}" 0 KiB

[ebuild   R   ~] dev-qt/qtwidgets-5.4.1:5::gentoo  USE="gles2 opengl png xcb -debug -gtkstyle% {-test}" 0 KiB

[ebuild   R    ] media-video/vlc-2.1.5-r1:0/5-7::gentoo  USE="X a52 aalib alsa avahi avcodec avformat bidi bluray cdda cddb dbus dirac dts dvb dvbpsi dvd egl encode faad ffmpeg flac fluidsynth fontconfig gcrypt gme gnutls* growl ieee1394 kate kde libass libav libcaca libnotify libsamplerate live matroska modplug mp3 mpeg mtp musepack ncurses ogg omxil opencv opengl png postproc pulseaudio qt4 rdp rtsp run-as-root samba schroedinger sdl skins speex svg swscale taglib theora truetype twolame udev upnp v4l vaapi vdpau* vnc vorbis x264 xcb xml xv (-altivec) -atmo (-audioqueue) -chromaprint -dc1394 -debug -directfb (-directx) (-dxva2) -fdk -gnome -httpd (-ios-vout) -jack -libtar -libtiger -linsys -lirc -lua (-macosx) (-macosx-audio) (-macosx-dialog-provider) (-macosx-eyetv) (-macosx-qtkit) (-macosx-quartztext) (-macosx-vout) (-media-library) (-neon) -optimisememory (-opus) -projectm -sdl-image -sftp -shout -sid {-test} -tremor -vcdx -vlm -wma-fixed -zvbi" CPU_FLAGS_X86="mmx sse" 0 KiB

[ebuild   R   ~] dev-qt/qtnetwork-5.4.1:5::gentoo  USE="networkmanager ssl -bindist% -connman -debug {-test}" 0 KiB

[ebuild     U  ] media-gfx/gimp-2.8.14:2::gentoo [2.8.10-r1:2::gentoo] USE="aalib alsa bzip2 curl dbus exif jpeg jpeg2k lcms mng pdf png postscript python smp svg tiff udev webkit wmf xpm (-altivec) (-aqua) -debug -doc -gnome" CPU_FLAGS_X86="mmx sse" LINGUAS="de -am -ar -ast -az -be -bg -br -ca -ca@valencia -cs -csb -da -dz -el -en_CA -en_GB -eo -es -et -eu -fa -fi -fr -ga -gl -gu -he -hi -hr -hu -id -is -it -ja -ka -kk -km -kn -ko -lt -lv -mk -ml -ms -my -nb -nds -ne -nl -nn -oc -pa -pl -pt -pt_BR -ro -ru -rw -si -sk -sl -sr -sr@latin -sv -ta -te -th -tr -tt -uk -vi -xh -yi -zh_CN -zh_HK -zh_TW" PYTHON_TARGETS="python2_7" 19.962 KiB

[blocks B      ] <media-video/libav-10_beta1 ("<media-video/libav-10_beta1" is blocking media-video/vlc-2.1.5-r1)

Total: 22 packages (18 upgrades, 4 reinstalls), Size of downloads: 224.056 KiB

Fetch Restriction: 1 package (1 unsatisfied)

Conflict: 1 block (1 unsatisfied)
```

Mir ist bis jetzt nichts dergleichen aufgefallen das die Version 2.1.5 von VLC nicht auch mit dem stable libav funktionieren würde.

----------

## franzf

Das geht eigentlich seit längerem so:

https://bugs.gentoo.org/show_bug.cgi?id=489606

Die Ausgabe deines emerge enthüll dann auch, dass du dem vlc ein USE="vdpau" spendiert hast  :Wink: 

Und ja, das ist doof :/

----------

## schmidicom

Ich dachte mir schon das es eines der useflags sein könnte die seit dem sync nun aktiv sind, aber trotzdem danke für den Buglink. Und irgendwie ist es schon beruhigend das es auch noch jemand anderem auffällt.

Auch wäre es nicht schlecht wenn portage einem in einer solchen Situation etwas konkreter mitteilen würde warum es blockt. Zum Beispiel so:

```
[blocks B      ] <media-video/libav-10_beta1 ("<media-video/libav-10_beta1" is blocking by media-video/vlc-2.1.5-r1[vdpau])
```

----------

## mv

 *schmidicom wrote:*   

> Auch wäre es nicht schlecht wenn portage einem in einer solchen Situation etwas konkreter mitteilen würde warum es blockt.

 

Das ist sehr schwer zu machen, wie auch gerade auf der gentoo.user Mailingliste besprochen:

Portage berechnet den Abhängigkeitsbaum aufgrund der gesetzten USE-Flags. Jede USE-Flag-Änderung bringt einen potentiell ganz anderen Baum mit sich, für den die Abhängigkeiten neu berechnet werden müssen.

In diesem Fall ist die Abhängigkeit "direkt", aber das muss ja keineswegs allgemein so sein... das Problem i.A. ist NP-vollständig.

----------

## Klaus Meier

Dazu kann ich nur sagen, dass ich mit libav beim Bauen von Paketen irgendwie sehr oft Probleme hatte. Mit ffmpeg funktioniert das wesentlich zuverlässiger. Ist ja jetzt auch wieder Standard. In Betrieb konnte ich keine Unterschiede feststellen. Wenn libav dich stresst, versuche es mal mit ffmpeg.

----------

## __bjoern

Ich hatte das selbe Problem. Hab aber dann einfach wieder auf ffmpeg umgestellt.

----------

## schmidicom

Ich weiß nicht mehr genau warum ich damals auf libav umgestiegen bin aber im Moment sehe ich noch keinen Grund das rückgängig zu machen. Ein paar Pakete musste ich auf wegen dem neueren libav auf testing anheben damit sie noch kompilieren aber so lange das nicht komplett aus dem Ruder läuft wird es fürs erste bei libav bleiben.

Man könnte vermutlich auch argumentieren das dies ein Anzeichen dafür ist das bei libav die Entwicklung wesentlich lebendiger abläuft als bei ffmpeg.

----------

## franzf

 *schmidicom wrote:*   

> Man könnte vermutlich auch argumentieren das dies ein Anzeichen dafür ist das bei libav die Entwicklung wesentlich lebendiger abläuft als bei ffmpeg.

 

Könnte man vermutlich nicht, denn das fragliche libav-10_beta1 hat Gentoo bereits am 20.2.2014 getroffen. In dem Zeitraum >1 Jahr gab es mehrere neue Releases in libav-8 und -9 das Problem wurde Upstream (libav) nicht gefixt, und auch Gentoo hat keine Revision mit dem Patch veröffentlicht.

Aber evtl. geht libav-11.3 bald stable, dann löst sich zumindest dieses Problem von allein...

----------

