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

В основном я использую Debian (иногда Ubuntu), а в репозиториях есть только одна или две основные версии, поэтому я не могу получить версию, которую требует источник.

Обычно я делаю одно из следующего:

  • Удалось получить нужную мне версию от apt-get (редко)

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

  • Выполните dist-upgrade (программное обеспечение, которое я скомпилировал до того, как перестанет работать, так как старые зависимости заменяются новыми)

  • Попытка установить зависимости без aptitude напрямую со стороннего сайта

Например, для источника требуется g++5, Debian Jessie имеет только 4 в своем репозитории или устанавливает общую библиотеку, такую ​​​​как libboost.

Каков наилучший способ управления зависимостями, недоступными в текущем источнике aptitude для дистрибутивов?

1
LinuxSecurityFreak 2 Фев 2018 в 11:33

1 ответ

TL;DR: используйте /usr/local или бэкпорты и упакуйте собственное программное обеспечение.

Начну с общего: дистрибутив — это целостная единица. Очевидно, что он существует для поддержки того, что его пользователи хотят делать помимо него, в разумных пределах (см. пункт 4 в Debian social контракт), но сначала он должен поддерживать сам себя; в частности, библиотеки, которые он содержит, в первую очередь потому, что они являются зависимостями от какой-то другой части программного обеспечения в дистрибутиве и пакетов -dev (или devel для читателей на стороне забора RPM) существуют ли они для того, чтобы упакованное программное обеспечение можно было собрать с помощью дистрибутива. Когда вы создаете программное обеспечение поверх дистрибутива, если библиотеки, включенные в дистрибутив, соответствуют вашим требованиям, это здорово, и вы можете их использовать; но если они этого не делают, вам следует избегать массирования дистрибутива для их обновления.

Некоторые среды разработки уже имеют дело с этим: у Python есть свои виртуальные среды, у Ruby есть что-то похожее, Java и NPM управляют своими собственными деревьями зависимостей для конкретных проектов и т. д. В экосистеме C/C++ на самом деле нет ничего подобного, кроме /usr/local, что может вполне соответствовать всем требованиям во многих случаях, в том числе, когда компилятор слишком стар.

На практике в экосистеме C/C++ есть несколько жизнеспособных решений.

  • Если вам нужен передний край, вы можете использовать «нестабильную» систему для своей разработки. Это не обязательно должна быть ваша полная система (вы должны делать это только в том случае, если вам удобно помогать Debian в разработке следующего выпуска), для этого очень хорошо подходит chroot; также обратите внимание, что «нестабильный» относится к стабильности ABI, а не к общей стабильности системы.

  • Если вам удобно управлять собственными зависимостями вручную, создайте свое программное обеспечение и его зависимости (которые недоступны в дистрибутиве) в /usr/local (и воспользуйтесь такими инструментами, как Stow для управления версиями).

  • Если вам просто нужно несколько обновленных зависимостей, рассмотрите возможность использования backports. В этом ответе объясняется, как устанавливать бэкпорты и даже создавать свои собственные; это позволит вам безопасно продолжать использовать пакеты с более новыми версиями, чем те, которые вы можете найти в текущей стабильной версии. Это действительно хорошо масштабируется, и многие организации поддерживают свои собственные репозитории бэкпортированных пакетов внутри.

Прежде всего, стоит научиться упаковывать программное обеспечение, которое вы создаете: это означает, что инструменты дистрибутива помогут вам обеспечить доступность зависимостей, что очень полезно при установке вашего программного обеспечения в других системах и при обновлении. Прекрасная практичная техника упаковки Debian Винсента Берната поможет вам в этом. быстро.

3
Stephen Kitt 2 Фев 2018 в 11:18