[devel] mplayer q

[Led]

В сообщении от Thursday 22 November 2007 13:59:01 Денис Смирнов написал(а):
> On Thu, Nov 22, 2007 at 12:00:27PM +0300, Alexey I. Froloff wrote:
> >> Без точечных обновлений можно будет обойтись когда у нас количество
>
>  AIF> [многабукф]
>
> >> хотел бы иметь возможность _запретить_ их существование в Сизифе в
> >> кривом виде.
>
> AIF> Вроде уже договорились, что пакеты из группы System/Legacy
> AIF> libraries не попадут ни в каком виде в дистрибутивы (и бранчи,
> AIF> надо бы добавить).
>
> Это не спасает, к сожалению.
>
> Смотри -- предположим завтра новая libdirectfb уйдет в бранч. Или в
> дистрибутив новый, что вероятнее.  Вроде все красиво?
>
> А потом человек имеющий старую инсталляцию (со старым libcairo) набирает:
> apt-get install mplayer и получает кривой mplayer.

Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт в 
сизиф. Вроде всё красиво? А ldd mplayer будет показывать libdirectfb-1.1 + 
libdirectfb-1.2, как будет работать и будет ли - неизвестно. Твои 
предложения?

> AIF> То, что предлагаешь делать ты, называется "отслеживание всех
> AIF> зависимостей вручную".  Зачем нам тогда findreq, buildreq и
> AIF> прочие rpm'ы-apt'ы?  Вон, в debian всё руками проставляют.
> AIF> А Сизиф - вообще не дистрибутив и кривизна тут допустима.
>
> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf) обматерил
> пакет. Вплоть до вывода в STDERR той строчки conflicts, которую человеку
> надо добавить в spec.

Ещё раз - посмотри всё дерево библиотек, которое использует mplayer прямо (это 
ещё как-то можно отследить, но с ними и так всё нормально разруливается по 
сонеймам), и косвено (их намного больше) - как их предлагаешь "отслеживать"? 
разве что постоянно , внимательно читать cyber-talks@ и анализировать КАЖДЫЙ 
обновлённый пакет: а не влияет ли он КОСВЕНО на mplayer?

ИМХО если библиотека обновилась - нужно срочно пересобрать ВСЁ, что с ней 
слинковано - либо роботом, либо уведеомлением мейнтейнера через багзиллу. 
Ориентироваться на возможность "точечного обновления" непродуктивно, для этих 
редких и нетривиальных случаев есть бэкпорты и бэкпортирование как таковое 
(хотя с переходом на git оно может "кануть в Лету" или быть на порядок 
затруднено).

Практика legacy-библиотек в репозитарии вносит беспорядок, непредсказуемые 
проблемы (как видно на примере mplayer) и отнимает время у мейнтейнеров для 
их сборки и поддержки.

> До полного перехода на сборку из git 
> автоматизировать это принципиально невозможно, после -- можно, но нелегко.

Будет git - будут другие проблемы. И я почему-то не уверен, что их будет 
меньше :(

-- 
Led