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

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

  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. Весь комплект оформляется как единый бинарник
    • ни с чем не кофликтует
    • можно копировать куда угодно — и оттуда запускать

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

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

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

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

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

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

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

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

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

  1. Вручную
    • Например, для сборки статического бинарника

  2. Autotools: все варианты, но окружение должно их поддерживать (например, /usr/local/lib должно быть в ld.so.conf)

    • $DESTDIR

    • ключи configure — тонкая настройка

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

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

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

Возможные TODO

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

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

TODO зафиксировать это время

План

Как это связано с нашим курсом?

Более подробные ссылки:

Д/З

LecturesCMC/LinuxApplicationDevelopment2024/12_InstallPackaging (последним исправлял пользователь FrBrGeorge 2024-12-03 18:17:30)