Как заставить библиотеки хорошо работать с пакетами Linux?

Я автор библиотеки C++, которая распространяется в составе нескольких дистрибутивов Linux. Библиотека включает заголовки и исходный код; Пакеты Linux распространяют его как заголовки + общая библиотека (.so).

Я ищу рекомендации, которые облегчили бы жизнь специалистам по сопровождению пакетов Linux.

Вещи, которые меня интересуют, включают:

  • Совместимость с API (например, изменение сигнатур функций). Очевидно, что поддержание совместимости между второстепенными выпусками имеет решающее значение. А как насчет основных изменений версии?

  • Двоичная совместимость (например, изменение размеров внешне видимых структур данных). Насколько важно быть совместимым с ABI во всех второстепенных выпусках? Есть ли проблемы со взломом в основных релизах?

  • Рекомендации по созданию версий. В настоящее время я использую CMake - какие-либо конкретные настройки, которые я должен установить, чтобы максимизировать вероятность того, что сопровождающие пакетов смогут просто использовать мой CMakeLists.txt?

Если есть что-то еще, чего мне не хватает, я тоже был бы рад услышать об этом.


c++ linux package-management
person zeuxcg    schedule 16.04.2015    source источник
comment
Это бесплатное программное обеспечение? Если да, вы можете возложить бремя упаковки на упаковщиков дистрибутива...   -  person Basile Starynkevitch    schedule 16.04.2015
comment
как вы планируете его упаковать? debian, redhat и slackware, например, используют разные механизмы пакетов (несовместимые)?   -  person Luis Colorado    schedule 17.04.2015
comment
@BasileStarynkevitch Лицензия Массачусетского технологического института. Сам не упаковываю - но мой вопрос как раз об этом - как облегчить жизнь упаковщикам дистрибутива   -  person zeuxcg    schedule 17.04.2015
comment
@LuisColorado Я не упаковываю его сам - разные люди упаковывают его для разных дистрибутивов.   -  person zeuxcg    schedule 17.04.2015

Ответы (2)


arrow_upward
2
arrow_downward

Как сопровождающий Linux я могу сказать, что для нас очень важна как обратная двоичная (ABI), так и исходная (API) совместимость вашей библиотеки.

Изменения API могут нарушить пересборку некоторых приложений (или других библиотек) в дистрибутиве, который зависит от вашей библиотеки. Это может нарушить массовое восстановление дистрибутива.

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

Если вы сломаете ABI, пожалуйста, измените SONAME вашей библиотеки (версия Bump). И, пожалуйста, не вносите изменения API/ABI в выпуски микро/патчей.

Я рекомендую вам использовать инструмент abi-compliance-checker для проверки вашей библиотеки на Обратная совместимость API/ABI. См. примеры отчетов инструмента для библиотеки Qt: http://abi-laboratory.pro/tracker/timeline/qt/

Вам необходимо скомпилировать отладочную версию вашей библиотеки с добавлением -g -Og опций и сделать дамп ABI вашей библиотеки с помощью инструмент abi-dumper. А затем сравните два дампа ABI разных версий, чтобы создать отчет об изменениях ABI.

введите здесь описание изображения

person linuxbuild    schedule 09.02.2016

arrow_upward
2
arrow_downward

Позвольте мне заняться частью ABI. Это во многом зависит от того, предоставите ли вы предварительно собранный двоичный файл, который будет работать везде, или вы полагаетесь на дистрибьюторов, которые создадут его для вас.

Возьмем Debian: как только пакет находится в Debian, узлы сборки перекомпилируют каждое обновление на каждой поддерживаемой платформе. C ABI редко меняется, но C++ ABI требует особого внимания (как упоминалось в этом сообщении 2005 года для разработчиков Debian: http://lwn.net/Articles/139810/)

Я не думаю, что разумно предоставлять пакет C++, который будет работать везде. ABI слишком зависит от сайта: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

person Rob Latham    schedule 16.04.2015
comment
Библиотека распространяется в виде заголовков+исходников; сопровождающие пакета создают его. Я больше имею в виду части ABI, контролируемые библиотекой, например. изменение размера класса. - person zeuxcg; 16.04.2015
comment
Информация о Debian интересна! Значит, для Debian важна только совместимость исходного кода, и не нужно ломать ABI на уровне библиотеки? - person zeuxcg; 16.04.2015