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/ ----------------------------------------------------------------------------