Re: [devel] SharedLibsPolicy

[Led <ledest@gmail.com>]

On Saturday, 14 November 2009 00:55:29 Michael Shigorin wrote:
> On Fri, Nov 13, 2009 at 11:39:49PM +0200, Led wrote:
> > > Так вот посмотри, что ты заявляешь: полиси, которое и не
> > > претендует на решение всех мировых проблем с разделяемыми
> > > библиотеками -- отбрасываешь на основании ряда узких частных
> > > случаев, где вообще-то уместен ещё и мозг майнтейнера.
> >
> > В текущем виде это полиси только упрятывает проблемы, в первую
> > очередь - от мейнтейнера, вылазят эти проблемы - уже у
> > пользователя. Только диагностировать их у пользователя
> > практически нереально.
>
> И что именно ты предлагаешь?  Чтоб были проблемы _и_
> с зависимостями, _и_ в ряде случаев -- с функциональностью?
>
> Я-то думал, что если майнтейнер не разгильдяй вроде меня,
> то по крайней мере сам сперва и наступит на грабли.
> Поскольку он есть и пользователь того, что напаковал.
> Если у себя на системе диагностировать тоже нереально
> (с помощью колег при нужде) -- то мы _уже_ приплыли.
>
> То есть продолжаю в упор не видеть, как именно упрятывает
> и что становится хуже.  Если можешь -- объясни терпеливо
> именно для меня.

Лично тебе я это объяснял "на пальцах" как минимум раза два. И возражений от 
тебя не было. Если ты этого не помнишь - ну... я тебе в чём-то завидую:)

>
> > > > соберу с новой библиотекой. результат - установить
> > > > одновременно, например, openoffice.org и mpd невозможно
> > >
> > > И чем была бы лучше ситуация при отсутствии как
> > > SharedLibsPolicy, так и возможности оперативно всех как
> > > минимум пересобрать, а порой ещё и пропатчить?
> >
> > В начале этого полиси следует написать большимы жирными буквати
> > "использовать только в крайнем случае, если другими методами
> > задача не решается"
>
> Если ты подразумеваешь ту часть, которая про упаковку библиотек
> с разными сонеймами, то она там не главная.  И её да, используют
> ровно тогда, когда это оказывается менее лениво (а порог здесь
> поднят и ACL-ками в том числе).
>
> Ну допиши, это же вики.  Только перечитай сперва, чтоб в начале
> того, к чему это утверждение на самом деле относится.

Оно относится ко всему полиси, которое как раз и описывает порядок "упаковки 
библиотек с разными сонеймами". Но там ничего не говорится, чем грозит 
наличие библиотек с разными сонеймами в одном ползовательском репозитарии и, 
тем более, в одном сборочном репозитарии.

>
> > > Вот возьми листик бумаги, подели на плюсы-минусы и опиши своё
> > > предложение (которого я не наблюдаю) против SLP.
> >
> > Тебе не кажется, что что-то рисовать, чтобы ко-му-то что-то
> > доказать - это пустая трата времени (ИМХО)?
>
> Валере предложил доказать в первую очередь себе -- наличие
> минусов от этого полиси, которых бы не было в его отсутствие.
>
> Отвечая на твой вопрос -- зависит.  Бывает пустая, бывает и нет.

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

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

Да. AFAIK чаще, чем ты. И сделал для себя вывод, что это нерационально и в 
конечном итоге - попытки "обмануть судьбу" с помощью безоглядного применения 
этого полиси приводят к непроизводительной пустой трате времени там, где его 
лучше потратить на решение проблемы, а не на её откладывание "на потом" 
(вдруг само рассосётся или кто-то другой решит).

-- 
Led