Недавно я узнал, что дистрибутивы на базе Debian по сути имеют фиксированный набор общих зависимостей и библиотек, которые должно использовать любое приложение, установленное через менеджер пакетов.
Сравните это, скажем, с Windows, где, как я считаю, каждое приложение обычно предоставляет свои собственные зависимости, и поэтому при установке ОС Windows экземпляры одних и тех же зависимостей/библиотек будут установлены много раз, и каждому приложению придется самостоятельно управлять обновлением этих зависимостей.
Я знаю, что некоторые разработчики создают свое программное обеспечение, совместимое с менеджером пакетов APT, но я предполагаю, что должно быть много приложений, где разработчики создали программное обеспечение в стиле «Windows».
Итак, мой вопрос заключается в следующем: если разработчики исходного кода создали свое программное обеспечение с намерением распространять большую монолитную установку, полностью укомплектованную зависимостями, должны ли сопровождающие пакеты APT переписывать исходный код так, чтобы программное обеспечение использовало общий набор зависимостей, а не локальные зависимости?
Если да, часто ли это происходит и является ли это серьезной задачей для специалистов по обслуживанию пакетов?
решение1
Итак, мой вопрос заключается в следующем: если разработчики исходного кода создали свое программное обеспечение с намерением распространять большую монолитную установку, полностью укомплектованную зависимостями, должны ли сопровождающие пакеты APT переписывать исходный код так, чтобы программное обеспечение использовало общий набор зависимостей, а не локальные зависимости?
Не обязательно, если только монолитная установка неконфликтс существующей библиотекой или именем файла. То есть, если в системе уже есть /lib/foobar
(версия 12), а монолитный пакет требует и связывает foobar
версию 9, то этот монолитный пакет не может хранить свою foobar
версию 9, используя имя файла /lib/foobar
, потому что этот путь занят -- но онмогиспользовать /lib/foobar_v9
, или возможно .../monolithic_app_dir/lib/foobar
.
Если да, часто ли это происходит и является ли это серьезной задачей для специалистов по обслуживанию пакетов?
Да, предотвращение и при необходимостисортировкаРазличные уровни ада зависимостей — это большая часть того, чем занимаются сопровождающие пакетов.
решение2
Политика Debianзаключается в том, что библиотеки, инструменты и т. д., входящие в комплект программы, должны быть отделены от нее при создании пакета Debian. Политика Debian также требует, чтобы библиотеки были разделены как минимум на пакет времени выполнения (например, libfoo-version
) и версию для разработки со статической библиотекой и заголовками (например, libfoo-version-dev
).
Что вы делаете в своей системе — это ваше личное дело, но любой разработчик Debian (DD), упаковывающий монолитное приложение, должен его разупаковать, то есть либо положиться на существующие библиотеки в Debian, либо создать для них пакеты, если их еще нет.
В других дистрибутивах могут действовать иные политики, но большинство из них требуют, чтобы пакеты в официальных репозиториях были разукрупнены, поскольку разукрупнение подрывает суть упаковки и затрудняет, например, применение обновлений безопасности библиотек ко всем программам, использующим определенную библиотеку.