[sisyphus] обновления... гм?!

[Денис Смирнов]

On Mon, Nov 15, 2010 at 02:39:24PM +0600, REAL wrote:

R> А вообще, Денис, если подводит память, я сам довольно часто на это 
R> полиси ссылался и являюсь её сторонником. Просто здесь ситуация иная.

Она отличается лишь тем, что в связи с особенностями ситуации (у
библиотеки очень мало клиентов) вред от несоблюдения этого полиси _сейчас_
отсутствует, и, если эта библиотека и в будущем будет столь же
редкоиспользуемой, то и будет отсутствовать.

R> Кстати, мне больше всего нравится идея, там не зафиксированная, но 
R> практикуемая некоторыми мейнтейнерами:
R> 1. самая новая версия пакета - без soname в названии.
R> 2. более старые (compat) - с soname.
R> Так красивее, на мой взгляд, и при этом сохраняется сама суть 
R> обсуждаемого полиси.

Суть -- да. В теории.

На практике -- apt кривая поделка, которая на этом склеит ласты и
потребует ручных усилий для обновления. А вся "красота" заключается в том,
что имя без soversion (то есть короче на один символ, и при этом не
содержит полезной информации). То есть красота исключительно визуальная, а
с технической точки зрения решение -- ужасное.

Объясняю еще раз. Библиотека это заведомо такая хрень, которая
пользователю не нужна. Вообще не нужна. И обновлять ее со сменой
soversion -- пользователю не нужно. 

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

А с точки зрения приложений в runtime (а не во время сборки) нету никакого
libabc, например. Есть libabc.1 или libabc.2. И если приложение хочет
libabc.1, то оно хочет _именно его_. А если другое хочет libabc.2, то оно
хочет _именно его_. Поэтому правильно относиться к libabc.1 и libabc.2 не
как к разным версиям библиотеки libabc, а как к двум совершенно разным
библиотекам.

Правда, к сожалению, у libabc.1 и libabc.2 высокая вероятность пересечения
по именам символов. И поэтому если по цепочке зависимостей у приложения
оказывается в памяти обе этих библиотеки, то будет большая проблема. В
принципе ровно та же проблема была бы если бы в памяти оказались libfoo и
libbar, у которых обеих почему-то есть символ foobar. Но уж вот такая
кривая вещь современные ОС, никакого namespace для этого не предусмотрено
к сожалению. 

Но я повторюсь -- libabc.1 и libabc.2 это не "разные версии одной
библиотеки". Это именно что разные библиотеки, с точки зрения системы.
Поэтому называть пакет с libabc2 просто libabc, а libabc1 --
libabc-compat, это, мягко скажем, попытка ввести кого-то в заблуждение.

Ибо если ты приходишь в магазин, например, то ты хочешь купить что-то. А
если это что-то лежит в закрытой коробочке с надписью "фрукт" -- а ты
хочешь что-то конкретное, то будешь ругаться на руководство этого магазина
нехорошими словами.

Вот 'libabc' это точно такая же вредная генерализация, вместо четкого
именования сущности которая находится в пакете. А сущность эта --
'libabc.1', или 'libabc.2' а не какой-нибудь там 'libabc', или, тем более
'libabc-compat' (который существует только в воображении мантейнера).

Подводя итог. Если пакет с библиотекой называется иначе чем
'lib%name.%soversion' мантейнер должен иметь четкое обоснование зачем это
нужно (какую цель это преследует). "и так сойдет в данной ситуации" -- это
не цель, а просто обоснование почему в данном случае неисполнение этого
полиси не является критической багой. Но багой оно в любом случае, до тех
пор пока нет конкретной цели, для достижения которой нарушение этого
полиси является необходимым инструментом.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20101115/84bb8bf5/attachment.bin>