Установка и пакетирование

Обратите внимание на то, что в «Практикуме» (репозиторий для предложений) рассматривается сборка полноценного пакета под платформу ALT.

• Понятие о Filesystem_Hierarchy_Standard

  • Выделенные каталоги для документации, man, библиотек, бинарноков и т. п.
  • Стандартные пути поиска ⇒ установка — это подкладывание в каталог…
• Установка («деплоймент»)

  1. … + перегенерация каких-то индексов (например, ldconfig или mandb )

  2. … + выполнение дополнительные действий в системе (задание спецпользователя, заведение пустой БД и т. п.)

  3. … + регистрация проделанной работы и установленных файлов для того, чтобы можно было удалить (деинсталлировать)

• Эксплуатационные зависимости и конфликты — это не ответственность инструментов сборки ⇒ понятие «Пакет операционной системы»

  0. Пакет — архив с деревом каталогов
  1. Пред/после установочные/деинсталляционные сценарии

     • Т. н. «хуки» — стандартные сценарии при появлении файлов особого вида (те же ldconfig или mandb)

  2. Эти же сценарии модифицируют систему
  3. Регистрация и деинсталляция пакета — стандартные системные действия

  4. Пакет содержит список эксплуатационных зависимостей — всегда можно проверить, есть ли они в системе

     • Специальные инструменты могут вычислять дерево зависимостей, скачать недостающие пакеты и подложть их в списоу установки

     • Рекурсивное удаление пакетов
  5. Проверка конфликтов, «альтернативы» (когда разные пакеты предоставляют одну и ту же сущность), …

Бонус пакетирования: сборка и формирование пакета не требуют прав root, установка полностью не зависима от исходников.

Варианты установки

0. Не устанавливать, запускать из каталога сборки
   • Работает для одного пользователя
   • Перемешивает продукт сборки и продукт эксплуатации (например, конфигурационные файлы)
   • Если нечто работает из каталога сборки, не факт ,что оно вообще сумеет работать после установки согласно FHS

   • Используется на начальных стадиях разработки

1. В систему, непосредственно в /usr/bin, /usr/lib64 и т. п.

   • «всё сразу работает»
   • требует права root
   • конфликтует с ПО из состава дистрибутива

   • Используется при пакетироовании

2. В систему, в выделенные каталоги /usr/local/bin, /usr/local/lib64 и т. п.

   • То же, но конфликт только с таким же сторонним ПО (зато более вероятный)

   • Не соответствует FHS

   • Используется при пакетировании в монолитных UNIX-like системах

3. В $HOME/.local/bin (…/bin, …/share, …/lib)

   • не требует прав root

     • ⇒ работает только у одного пользователя
     • ⇒ могут не заработать «дополнительные действия»

   • Используется в пакетных системах, ориентированных на разработчика (python, ruby, node и т. п.)

     • ⇒ Для собственно разработки требует нескольких независимых пространств установки (venv в Python)

     • А для пользователя оказывается даже сложнее установки пакета

4. В отдельный подкаталог /opt/приложение/bin (…/bin, …/share, …/lib)

   • ни с чем не конфликтует
   • требует права root
   • как правило, требует дополнительной настройки при старте (нестандартное место библиотек и т. п.), обычно — в обёрточных шелл-сценариях

   • Используется в несвободных / сложных «any linux» проектах (когда надо тащить с собой бинарники и библиотеки)

5. Гибридная: одна из предыдущих схем + статическая компоновка с частью библиотек
   • Довольно проста в эксплуатации
   • Сочетает в себе недостатки статической сборки и выбранной схемы
   • Может привести к разноверсице прямо в бинарнике (между кодом статической библиотеки и внезапной динамической зависимостью на неё же)

   • Используется при разработке небольших средних приложений на высокоуровневых инструментариях, например, Qt (Telegram desktop Linux)

6. Монолитная: весь комплект оформляется как единый бинарник (статический или минимально гибридный: динамический с зависимостью только на glibc)

   • ни с чем не кофликтует
   • можно копировать куда угодно — и оттуда запускать

   • не требует прав root

   • требует монолитной сборки (неважно, статической или динамической)
     • снимает проблему поиска требуемых библиотек при динамической линковке
     • частично снимает разноверсицу системных и требуемых библиотек
     • сильно увеличивает объём
   • ⇒ Требует для сборки статической версии всех библиотек
     • ⇒ Возможно, потребуется пересборка этих библиотек вместе с проектом
     • - фиксирует ABI используемых библиотек (в том числе ошибочное и устаревшее)

     • агитка от Ульриха Дреппера против статической сборки

   • Требует программной поддержки «ресурсов»: данные должны храниться не в виде отдельных файлов, а в виде прикомпилированных программно доступных объектов

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

Простой пример: pcre2demo и статическая libpcre2_8:

• cc pcredemo.с -lpcre2-8 — динамическая

• cc pcredemo.с -static -lpcre2-8 — полностью статическая

• cc pcredemo.с /usr/lib64/libpcre2-8.a — гибридная

Поддержка вариантов установки в системах сборки

0. Вручную
   • Например, для сборки статического бинарника
   • GNU Make — нет выделенных инструментов установки!

     • А как же make install? А никак, без дополнительных инструментов это ручные действия.

1. Autotools, AKA «configure - make - make install» AKA «Крибле! Крабле! Бумс!»

   • Все варианты, кроме №0 (без установки), но окружение должно их поддерживать (например, /usr/local/lib должно быть в ld.so.conf)

   • $DESTDIR

   • Ключи configure «--…dir=DIR»

     • тонкая настройка с помощью configure.ac

   • Надо сильно поупражняться для полностью статической сборки

   • Наш пример простейшей локализации поддерживает способ №2 «из коробки», а также №1, №3 и №4

2. Libtool: все варианты + поддержка со стороны окружения (за счёт сценариев, .la-файлов и т. п.)

   • Используется только для тестовой установки после локальной сборки. Кажется, установка в /opt/… должна поддерживаться хорошо, но прецедентов я не помню

3. CMake: cmake --install

   • Изобрели только в 2019 году

   • у меня были сложности с этим: очень часто CMake-проекты рассчитаны на запуск из каталога сборки, метод №0

4. Meson: meson install

Введение в пакетирование

(сильно зависит от оставшегося времени)

Пакетирование отражает дисциплину разработки в конкретном Linux-сообществе (вплоть до различий форматах пакета, даже если они называются одинаково):

• Собственно формат (rpm, deb, aur, portage и т. д.)
• Сценарий сборки
• Сценарий установки в т. н. BUILDROOT
• Дисциплина именования и размещения файлов
• Хуки и установочные сценарии; (Debian-based) конфигурацонные сценарии
• Дисциплина организации сборочного окружения.

Создание (сборка) пакета:

• Создание спецификации (метаинформация, зависимости, команды сборки и установки и т. п.)

• Автоматизированная сборка на основе спецификации
• Автоматизированная установка BUILDROOT на основе спецификации
• Формирование архива с корнем вместо BUILDROOT со всей дополнительной метаинформацией (это и есть пакет)

Пакеты в ALT Linux Team:

• Руководство по сборке RPM-пакетов для дистрибутивов Альт

• Технология сборки пакетов RPM — покороче и попроще

• Практикум по нашему курсу на базе «Альт Платформы»

• Лекция 2020 года

• Лекция 2022 года

• Про пакеты в учебнике

(если вдруг останется ещё время)

Пакеты → репозиторий → дистрибутивы

• Свободное лицензирование
• Пакеты и майнтейнеры
• Репозитории пакетов и сборочные сервера
• Дистрибутивы

Д/З

1. Финальный проект. Сделать новый проект любого уровня тупости (можно просто какое-нибудь Д/З, но интереснее что-то новое?). В проекте должны быть (в любом невырожденном объёме):
   • Инструмент адаптации к окружению (autotools или аналоги)
   • Сборка динамической библиотеки, с которой будет собираться программа
   • Перевод сообщений
   • Unit-тесты
   • Manpage
   • Выгонка документации из исходников + описание проекта (в частности, инструкция по сборке и установке)

   • внимание, опасно!

     • Установка в систему от root-а (разумеется, включая документацию, manpage и библиотеку)
     • Деинсталляция от root-а

     • (лучше сначала потренироваться на установке от пользователя в /tmp/qq)

   • Установленная от root программа должна работать в двух локалях, manpage должен читаться командой man

2. В репозитории с домашними заданиями создать подкаталог 12_InstallPackaging и положить решение туда