[devel] SharedLibsPolicy

[Led]

On Friday, 13 November 2009 23:25:26 Michael Shigorin wrote:
> On Fri, Nov 13, 2009 at 11:36:32AM +0300, Valery V. Inozemtsev wrote:
> > как говорится утро вечера мудренее... по мотивам #22272
>
> ...намудрил, да.
>
> > Пример 1:
> > libbluez/libbluez3, хотя здесь лучше сказать
> > libbluetooth.so.2/libbluetooth.so.3, что бы не было путаницы.
> > если рассматривать эту библиотеку как библиотеку, то все
> > замечательно, зависимости удовлетворены, пакеты пересборку
> > проходят. но вот оказия, отдельно эта библиотека совершенно
> > бесполезна, т.е. нужно еще что то для управления всей
> > подсистемой bluetooth и это что то bluetoothd из пакета
> > bluez-4.XX. почему не hcid из bluez-utils? потому что если ты
> > не "чёкнутый профессор", помимо {bluetooth,hci}d понадобится
> > gnome-bluetooth/blueman/kbluetooth, которые собраны с
> > libbluetooth.so.3 и нужен им bluez-4.XX. пользователь ставит
> > тот же gammu и долго удивляется, почему же он не работает?
>
> Спасибо тебе за эпитет, а только "пользователь" для тебя уже
> как вот здесь описано: http://lwn.net/Articles/357366/?
> Мне эти блюеманы не сдались трижды.  kdebluetooth (третий)
> раз в пятилетку применяю при спаривании, после переезда на
> dbus не получается пользоваться нормальным PIN-скриптом.
>
> Так вот посмотри, что ты заявляешь: полиси, которое и не
> претендует на решение всех мировых проблем с разделяемыми
> библиотеками -- отбрасываешь на основании ряда узких частных
> случаев, где вообще-то уместен ещё и мозг майнтейнера.

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

> Несмотря на то, что для гораздо более типичных случаев это
> полиси либо ничем не вредит, либо тупо выручает как майнтейнеров
> связанных по зависимостям на какую-либо библиотеку пакетов,
> так и пользователей, которым переживать такие переезды и хорошо
> бы без ставшего многим привычным порыва апта снести полсистемы.
>
> (да, и gammu у меня *работает*, что от него и требуется)
>
> > Пример 2:
> > libpolkit/libpolkit1. полиси соблюдены, пожалуйста собирайте KDE4 с
> > polkit, gnome-2.28 с polkit1. но тут опять бяда - кто то из них будет
> > работать не так, как предполагалось. оказывается сам по себе polkit
> > работать не может, ему нужен ConsoleKit и рабочим будет тот polkit с
> > которым слинкован ConsoleKit
>
> Возможно ли это выразить в терминах Conflicts:?
>
> > Пример 3:
>
> [...]
>
> > т.к. таск 15301 канул в лету, соблюдем полиси и обзовем их
> > libcdio и libcdio82 с provides/conflicts. gst-plugins-ugly я
> > естественно соберу с новой библиотекой. результат - установить
> > одновременно, например, openoffice.org и mpd невозможно
>
> И чем была бы лучше ситуация при отсутствии как SharedLibsPolicy,
> так и возможности оперативно всех как минимум пересобрать,
> а порой ещё и пропатчить?

В начале этого полиси следует написать большимы жирными буквати "использовать 
только в крайнем случае, если другими методами задача не решается"

>
> Вот возьми листик бумаги, подели на плюсы-минусы и опиши своё
> предложение (которого я не наблюдаю) против SLP.

Тебе не кажется, что что-то рисовать, чтобы ко-му-то что-то доказать - это 
пустая трата времени (ИМХО)?

>
> > а теперь вопрос: так что же мы хотим, что бы пакеты собирались
> > и имели удовлетворенные зависимости, но при этом они либо
> > оказываются не рабочими, либо вместе не живут; или все же что
> > бы можно было эти пакеты установить не каждый по отдельности, а
> > вместе, да при этом еще, о чудо, они будут работать?
>
> Полиси может помось с "собирались и имели", а со всем остальным
> задача _остаётся_ на майнтейнере.

Мне не очень импонирует идея, чтобы пакеты "имели" пользователя.

>
> Или предлагается молоток выкинуть и гвозди руками забивать?
> Ну так молоток и не решает вопроса, куда бить и какой длиной.
>
> > P.S. вспоминая зоопарк с libneonXX... была кучка пакетов
> > собранная с 3-ми, 4-мя неонами, я потратил несколько часов на
> > то что бы собрать их с libneon последней версии.  сколько
> > времени потребуется отдельно взятому мантейнеру на починку
> > одного пакета и стоит ли плодить четыре одинаковых библиотек с
> > разным soname?
>
> Ну да, ну да.  Это время делится на въезд в проблему и N кусочков
> исправления конкретных ситуаций.  Баланс может быть сильно
> разным, нередко въезд намного дороже конкретного исправления
> (и одному человеку разобраться и починить пачку пакетов намного
> быстрее, чем N человекам N раз разобраться и починить по пакету).
>
> Что характерно, это уже высказывалось и некоторыми майнтейнерами
> было принято во внимание на практике -- они стараются помогать
> коллегам, делясь анализом типичных разломов.
>
> PS: помимо дебиана, lib%name%soname давно используется как
> минимум в mandriva и opensuse, и чуточку -- даже в федоре.



-- 
Led