Правильное определение файла спецификации для обновления библиотек

Есть библиотечный пакет, за распространение которого я отвечаю. Некоторое время назад система сборки была переключена с нашей домашней выпечки Makefileна использование GNU Autotools. Таким образом , используяlibtool, мы теперь имеем возможность легко управлять несколькими установленными версиями библиотеки. Переключившись на RPM для распространения, я хотел бы знать, как я могу «доктор» файл спецификации, чтобы воздержаться от полного удаления предыдущих версий при обновлении.

Например, после установки версии 1.0.0 фиктивного проекта библиотеки у меня есть

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby*
/usr/lib64/libabyss.a   /usr/lib64/libabyss.so    /usr/lib64/libabyss.so.0.0.0
/usr/lib64/libabyss.la  /usr/lib64/libabyss.so.0

Затем, после sudo yum localupdate ....того, как у меня есть следующее:

[afalanga@afalanga4 libtest]$ ls /usr/lib64/libaby*
/usr/lib64/libabyss.a   /usr/lib64/libabyss.so    /usr/lib64/libabyss.so.0.0.1
/usr/lib64/libabyss.la  /usr/lib64/libabyss.so.0

Конечно, как библиотека, созданная libtool, единственными «реальными» файлами являются: libabyss.a, libabyss.la and libabyss.so.0.0.1. Что нужно сделать в файле spec, чтобы убедиться, что libabyss.so.0.0.0stays after libabyss.so.0.0.1установлен? О символических связях позаботятся соответствующим образом.

2 ответа

  1. Не существует реального способа сделать то, что вы пытаетесь сделать, потому что символическая ссылка, используемая для загрузки библиотеки, управляется ldconfigи основана на SONAME библиотеки (см. мою публикацию по теме . Так что даже если вы .so.0.0.1ничего не сохранили бы никогда не будет использовать его.

    Если вы хотите их для совместимости, потому что они могут отличаться от ABI, то вам придется убедиться, что управление версиями сделано правильно, но это не похоже на случай из того, что я могу прочитать.

    Кроме этого, я не уверен, что RPM имеет какой-то особый случай, чтобы сохранить несколько версий данной библиотеки в этих случаях, потому что на самом деле не должно быть необходимости в этом.

  2. Ну, это не сработает. Обычное допущение GNU Build System для управления версиями библиотек заключается в использовании схемы, описанной здесь, для вычисления значений, которые вы задаете -version-info. Как упоминал Диего, даже если вы смогли убедить RPM оставить эти старые libs вокруг (IIRC, я думаю, что вы можете, когда rpm запускается), старые версии совместно используют тот же SONAME, что и старый (напримерlibabyss.so.0), и по существу будут осиротевшими при ldconfigзапуске на установке/обновлении библиотеки.

    Обычно, когда люди хотят сделать это , они будут использовать флаг libtool -releaseили переименовать пакет RPMlibabyss0, какlibabyss1, и т.д. чтобы поместить номер версии SONAME вперед.