[devel] Сборка ffmpeg в p8

[Vitaly Lipatov]

Всем добрый день!

Вопрос о сборке ffmpeg в p8 очень интересный, потому что попытки его 
решения выявляют ряд проблем и ограничений, многие из которых не носят 
технического характера.
Так получилось, что так или иначе тему ffmpeg я обсуждал с разными 
специалистами, но они не всегда знали мнение друг друга, поэтому я хотел 
бы их увидеть в этой цепочке обсуждения.

На самом деле я очень мало разбираюсь в проблеме. Я не собирал ffmpeg, и 
не проводил ту большую работу, которую провёл rider@ в Сизифе, благодаря 
которой мы не только получили актуальную версию ffmpeg, но и знаем 
теперь о том, что переход возможен.

Итак. Как обычно, всё начинается с того, что почти все программы, 
хотящие воспроизводить видео, хотят использовать ffmpeg. Которого — 
неожиданно — в p8 нет.

Среди них такие базовые в наше время программы, как chromium и firefox.
Кстати, у них интересное отличие. Если chromium просто несёт ffmpeg 
внутри себя и собирает его в библиотеку, которую носит с собой, то 
firefox носит с собой некоторые огрызки и headers, а потом при 
исполнении перебирает по списку, что он может загрузить из
   "libavcodec-ffmpeg.so.57",
   "libavcodec-ffmpeg.so.56",
   "libavcodec.so.57",
   "libavcodec.so.56",
   "libavcodec.so.55",
   "libavcodec.so.54",
   "libavcodec.so.53",

Что интересно с chromium. Многие библиотеки, которые он несёт с собой, 
он собирает динамически и кладёт в свой каталог:
/usr/lib64/chromium/libffmpeg.so
/usr/lib64/chromium/libicui18n.so
/usr/lib64/chromium/libicuuc.so
/usr/lib64/chromium/libv8.so

Кто даёт гарантии, что какие-то библиотеки, используемые chromium, не 
слинкуются с какими-то системными вариантами этих библиотек и chromium 
не начнёт падать?
В тоже время один из аргументов против моего робкого предложения собрать 
ffmpeg в %_libdir/ffmpeg, чтобы он никому не мешал кроме тех, кто решит 
явно с ним линковаться, заключается как раз в попытке избежать такой 
ситуации.

Далее. Сейчас очень популярным является создание desktop-программ на 
движке Electon (всё началось с редактора Atom, потом MS Visual Studio 
Code, клиенты Skype, VK Messenger, разные там Franz, WebTorrent, 
PopcornTime, Sia UI и пр).
Если посмотреть на то, как electron собран, видно, с какими библиотеками 
он собран или носит с собой.
$ rpm -ql electron
/usr/lib64/electron/electron
/usr/lib64/electron/icudtl.dat
/usr/lib64/electron/libffmpeg.so
/usr/lib64/electron/libnode.so

Возможность собрать крупный проект, используя системные библиотеки 
дистрибутива — это свойство не только проекта, но ещё и показатель 
зрелости дистрибутива. Это же простой вопрос — можно ли построить на 
платформе что-то стабильное, или всё надо принести с собой.

Вот у нас (а может только у меня в системе) есть 3 библиотеки libpng 
одновременно:
$ ls /usr/lib64/libpng*.so.*.0 -1
/usr/lib64/libpng12.so.0.50.0
/usr/lib64/libpng15.so.15.28.0
/usr/lib64/libpng16.so.16.29.0
и этого не пугает никого.
В тоже время появление альтернативных библиотек ffmpeg выглядит страшно.

Я слышал простое предложение носить линковаться с ffmpeg статически. 
Конечно, я никогда не стану собирать незаметно ffmpeg внутри пакета и 
линковаться с ней. Я бы собрал некий ffmpeg-devel-static со статическими 
библиотеками и собирался с ней. Но если мы на простой проблеме так легко 
отказываемся от динамической линковки, зачем в других случаях 
рассказывать, как важно иметь возможность в случае необходимости 
пересобирать библиотеку с security fixes, не пересобирая все проекты, её 
использующие.
Я уж молчу о разделении памяти и совсем отдельная тема, что смена 
способа линковки может вызывать лицензионные столкновения.

Затрудняюсь привести все аргументы против сборки в p8, которые я услышал 
от уважаемых коллег. Мне показалось, что частично они защищают 
репозиторий от недальновидных мантейнеров, а частично выглядят немного 
смешно. И почти не носят технический характер. Поэтому я прошу, если 
аргументы против остались в силе, процитировать их здесь самостоятельно.

Закончу фразой, что репозиторий, в который нельзя собрать пакет, 
становится не интересен.


P.S.
А mplayer в Сизифе слинкован с десятками сумасшедших библиотек проекта 
samba. Видимо, со всем содержимым
/usr/lib64/samba/:
...
	libutil-tdb-samba4.so => /usr/lib64/samba/libutil-tdb-samba4.so 
(0x00007f3138760000)
	libsamba-sockets-samba4.so => 
/usr/lib64/samba/libsamba-sockets-samba4.so (0x00007f3138548000)
...

$ ldd /usr/bin/mplayer | grep samba | wc -l
54


-- 
С уважением,
Виталий Липатов,
Etersoft