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

• Понятие о Filesystem_Hierarchy_Standard

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

  • … + перегенерация каких-то индексов (стандартная, например, ld.so.conf)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   • ни с чем не кофликтует
   • требует права root
   • как правило, требует дополнительной настройки при старте (нестандартное место библиотек и т. п.)

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

4. Весь комплект оформляется как единый бинарник
   • ни с чем не кофликтует
   • можно копировать куда угодно — и оттуда запускать

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

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

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

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

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

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

   • $DESTDIR

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

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

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

TODO

• Пример статической сборки
• Разбор обычного autotools-генерата
• Разбоор libtool-генерата

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

TODO примерно из этой лекции LecturesCMC/LinuxApplicationDevelopment2020/14_PackagesDistro

• + Из прошлогодней

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

TODO План

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

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

Д/З

TODO Здесь должно было быть задание на установку ПО в живую систему, но пока непонятно, что делать с правами root, а установка в домашний каталог выглядит как-то уж совсем странно.

В 2023 году Д/З не будет, но надо подумать про установку в домашний каталог в ~/.local/

• Что делать, если система не поддерживает ~/.local/lib/, то есть ldconfig vs LD_LIBRARY_PATH, вот это всё

• Что делать, если система не включает по умолчанию ~/.local/bin/ в PATH (включать руками или страдать).