Вход:  Пароль:  
FreeSource: AltLinux/Policy/Drafts/SharedLibs ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия AltLinux/Policy/Drafts/SharedLibs за 2007-08-25 17:38:28..

Предпосылки


Библиотеки могут потенциально использоваться многими программами, из-за чего несовместимое изменение интерфейса любой библиотеки требует большого объёма работы по адаптации её клиентов. Для упрощения процесса переезда и уменьшения количества сломанных в каждый конкретный момент времени пакетов библиотеки различных несовместимых версий должны уметь сосуществовать на одной машинке.

Упаковка библиотек


Библиотека должна быть упакована в пакет, имя которого меняется, когда меняется версия разделяемой библиотеки. Обычно используются конструкции вида lib%name%soversion, где %soversion — версия библиотеки. Если же библиотека и так содержит цифру в конце своего имени, допустимо именовать пакет в виде lib%name-%soversion.


Пакеты с development-частями библиотек должны быть поименованы lib%name%soversion-devel, если планируется поддерживать несколько development-версий для разных версий библиотек (что далеко не всегда оправданно, см. ниже) или lib%name-devel для последней версии библиотеки.


Таким образом, именование пакетов вида lib%name%soversion и lib%name-devel позволит избавиться от проблем с обновлениями пакетов, когда они не пересобраны с новой библиотекой.

Выбор правильного %soversion в имени пакета


В зависимости от действий/политики upstream, %soversion в имени пакета может иметь разный вид. К примеру, для QT достаточно major-версии soname, т.к. libqt4 обратно не совместима с libqt3, а в случае с некоторыми другими библиотеками может понадобиться полное указание soname, например, libdb4.3 и libdb4.4.

Переезд со старого именования


Не секрет, что сейчас в Сизифе подобным образом запакованы очень немногие библиотеки. Предположим, что библиотека libfoo обновилась и в ней сменился soname с N на M.


При сборке новой версии пакета libfoo предлагается сделать следующее:
1. Переименовать пакет libfoo в libfooM
2. Добавить в пакет libfooM Provides: libfoo = %version-%release

Политика адаптации клиентов разделяемых библиотек к новым версиям


За исключением особых случаев (например, qt3 и qt4, которые по сути являются различными библиотеками, а не разными версиями одной), настоятельно рекомендуется поддерживать наличие ровно одного -devel пакета (соответствующего самой новой версии библиотеки) для любой библиотеки, сколько бы старых версий этой библиотеки не присутствовало в Сизифе. При выполнении этого правила новые собираемые версии клиентов библиотек будут автоматически собираться с новой версией библиотеки (см. тж. http://lists.altlinux.org/pipermail/devel/2006-December/039664.html). В виде исключения, если новая версия библиотеки приводит к несобираемости большого количества пакетов, допустимо поддерживать две версии пакетов -devel, с соответствующим разделением зависимых пакетов на собирающиеся с новой и со старой версией библиотеки.


Старые библиотеки должны быть перемещены в группу 'System/Legacy libraries' при появлении в Сизифе новой версии. Аналогично пакетам -devel, в исключительных случаях разрешается иметь более одной версии библиотеки не в Legacy.


Когда библиотека из группы 'System/Legacy libraries' не требуется ни одним пакетом из Сизифа, она должна быть удалена из него. Пакеты из группы 'System/Legacy Libraries' (и, соответственно, пакеты, зависящие от них) объявляются непригодными к выпуску в стабильной версии Sisyphus.

Бэкпорты


Поскольку предлагаемое изменение именования библиотек жёстко прикрепляет soname к имени пакета, а также позволяет сосуществовать разным версиям библиотек, становится возможным бэкпортить новые версии библиотек и программы, зависящие от новых версий библиотек, что значительно ослабляет условие 5 в backports policy.

Ссылки



Страницы, ссылающиеся на данную: AltLinux/Sisyphus/SolutionProcess


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]