Вход:  Пароль:  
FreeSource: AltLinux/Policy/Drafts/SharedLibs ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия AltLinux/Policy/Drafts/SharedLibs за 2007-10-13 15:24:43..

Предпосылки


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

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


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


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


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

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


В случае, если существует несколько поддерживаемых веток одной библиотеки, %soversion может соответствовать major-версии библиотеки (libqt3, libqt4) или иметь вид major.minor (libdb4.0, libdb4.1). Можно также использовать часть soname'а библиотеки (напр., libcurl4, libflac8).

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


Не секрет, что сейчас в Сизифе подобным образом запакованы очень немногие библиотеки. Предположим, что библиотека 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, с проставлением тегов Conflicts в этих пакетах -devel друг на друга и соответствующим разделением зависимых пакетов на собирающиеся с новой и со старой версией библиотеки.


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


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

Бэкпорты


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

Ссылки



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


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