Re: [devel] mplayer q

[led@altlinux.ru]

Friday, 23 November 2007 17:54:09 Денис Смирнов написав:
> On Thu, Nov 22, 2007 at 03:04:48PM +0200, Led wrote:
>
> L> Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт
> в L> сизиф. Вроде всё красиво? А ldd mplayer будет показывать
> libdirectfb-1.1 + L> libdirectfb-1.2, как будет работать и будет ли -
> неизвестно. Твои L> предложения?
>
> Хороший вопрос. Ты прав.
>
> >> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf)
> >> обматерил пакет. Вплоть до вывода в STDERR той строчки conflicts,
> >> которую человеку надо добавить в spec.
>
> L> Ещё раз - посмотри всё дерево библиотек, которое использует mplayer
> прямо (это L> ещё как-то можно отследить, но с ними и так всё нормально
> разруливается по L> сонеймам), и косвено (их намного больше) - как их
> предлагаешь "отслеживать"? L> разве что постоянно , внимательно читать
> cyber-talks@ и анализировать КАЖДЫЙ L> обновлённый пакет: а не влияет ли он
> КОСВЕНО на mplayer?
>
> Это должен делать робот, или не делать никто.

Т.е. робот должен заворачивать вполне корректный пакет mplayer из-за разнобоя, 
вносимых legacy-библиотеками в репозитарии? И будет заворачивать до тех пор, 
пока "вдруг" этот разнобой каким-то образом, случайно исчезнет? Или я просто 
неправильно тебя понял?

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

Наверное, иногда необходима... Я просто думал, что вариант с бэкпортами 
подойдёт для таких редких случаев. Но, возможно, я и неправ...

>
> L> Практика legacy-библиотек в репозитарии вносит беспорядок,
> непредсказуемые L> проблемы (как видно на примере mplayer) и отнимает время
> у мейнтейнеров для L> их сборки и поддержки.
>
> А с этим я полностью согласен. Только ты предлагаешь использовать это
> чтобы замаскировать другую проблему.

И с этим я полностьб согласен:) Я прелагаю это, потому как пока не вижу других 
решений :(

>
> >> До полного перехода на сборку из git
> >> автоматизировать это принципиально невозможно, после -- можно, но
> >> нелегко.
>
> L> Будет git - будут другие проблемы. И я почему-то не уверен, что их будет
> L> меньше :(
>
> Они будет именно что сильно другими.

В том-то и дело, что они не исчезнут :(

___
Led.