Влияние компиляции из исходного кода на уже установленные приложения


8

Я использую Ubuntu 12.04. Скажем, я установил package xиз репозитория (со всеми его зависимостями) в версии 1.7, но мне нужны некоторые функции, которые доступны только в версии 1.8, поэтому я загружаю исходный tar и скомпилирую его:

./configure  
make  
make install
  • Это перезаписывает существующие двоичные файлы 1.7?
  • Если существующие двоичные файлы перезаписаны, отражает ли менеджер пакетов новую версию (1.8) и может ли он package xбыть обновлен диспетчером пакетов в будущем?
  • Если package yесть зависимость package x 1.8- будет ли она удовлетворена?

Я пытался найти хороший источник в Интернете, который объясняет это. Если у Вас есть какие-либо рекомендации, пожалуйста, дайте мне знать.


Если вы намеренно обойти менеджер пакетов, то , что на земле заставляет вас думать , что это впоследствии будет признать , что вы установили?
Шадур

@Shadur Этот аспект этого вопроса в основном сводится к вопросу о том, что происходит, именно тогда , когда вы устанавливаете программное обеспечение из исходного кода make install. Я думаю, из ответов ясно, что, по сути, все, что происходит, - это то, что файлы копируются в каталоги внутри префикса установки (хотя оказывается, что возможно, что некоторые файлы конфигурации могут быть вставлены, /etcа некоторые динамически изменяемые данные, представляющие исходный состояние чего то можно поставить /var). Однако, если вы чувствуете, что это не ясно, я был бы рад отредактировать мой ответ, чтобы объяснить.
Элия ​​Каган

@EliahKagan Там я в основном разговаривал с Филиппом.
Шадур

Ответы:


12

Подавляющее большинство .debпакетов, независимо от того, предоставляются они официальными репозиториями или нет, устанавливаются с префиксом /usr.

Это означает, что исполняемые файлы, предназначенные для запуска пользователем, входят /usr/binили /usr/sbin(или, /usr/gamesесли это игра), общие библиотеки включаются /usr/lib, независимые от платформы общие данные включаются /usr/share, заголовочные файлы включаются /usr/include, а исходный код устанавливается автоматически /usr/src.

Небольшой процент пакетов используют /в качестве префикса. Например, bashпакет помещает bashисполняемый файл /bin, а не /usr/bin. Это для пакетов , которые обеспечивают самое необходимое для работы в однопользовательском режиме (например, режим восстановления) и начать многопользовательский режим (но помните, что часто включает в себя функциональные возможности для монтирования некоторых видов сетевых акций ... в случае , если /usrэто удаленная файловая система).

Небольшой процент .debпакетов, в основном, созданных с помощью Quickly , создает папку для конкретного пакета внутри /optи помещает туда все свои файлы. Кроме этого, большую часть времени /optэто местоположение, используемое программным обеспечением, которое устанавливается из исполняемого установщика, который не использует системный менеджер пакетов, но не включает компиляцию из исходного кода. (Например, если вы устанавливаете проприетарную программу, такую ​​как MATLAB, вы, вероятно, вставите ее /opt.)

В отличие от всего этого, когда вы загружаете исходный архив (или получаете исходный код из системы контроля версий, такой как Bazaar или git), собираете его и устанавливаете его, он обычно устанавливается в префикс /usr/local(если вы не скажете ему сделать это). в противном случае). Это означает , что ваши исполняемые файлы идут в /usr/local/bin, /usr/local/libили /usr/local/games, ваши библиотеки /usr/local/lib, и так далее.

Есть некоторые исключения из этого - некоторые программы по умолчанию устанавливаются в /usrпрефикс и, таким образом, перезаписывают установки тех же программ из .debпакетов. Как правило, вы можете предотвратить это, запустив ./configure --prefix=/usr/localвместо того, ./configureчтобы создавать их. Я еще раз подчеркиваю, что обычно в этом нет необходимости.

(По этой причине для вас имеет смысл поместить исходный код, который вы создаете, и который будет установлен для общесистемного использования /usr/local/src, которое существует для этой цели.)

Предполагая, что упакованная версия установлена ​​в /usrи версия, которую вы установили из источника, находится в /usr/local:

  • Файлы из установленного пакета не будут перезаписаны.

    Обычно более новая версия запускается, когда вы вручную вызываете программу из командной строки (при условии, /usr/local/binчто исполняемые файлы или где они установлены, находятся в PATHпеременной среды и отображаются перед соответствующим /usrкаталогом с префиксом, например /usr/bin).

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

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

Однако, если по какой-либо причине файлы перезаписываются (например, если исходный код установлен /usrвместо /usr/local):

  • Менеджер пакетов не будет ничего знать о том, как было изменено установленное программное обеспечение. Он будет думать, что старая версия установлена. Могут возникнуть плохие проблемы. Вам следует избегать этого. Если вы создали эту ситуацию, вам следует удалить программное обеспечение, которое вы установили из источника (обычно sudo make uninstallв каталоге), а затем удалить пакет или пакеты, содержащие файлы, которые были перезаписаны (поскольку они не будут восстановлены при удалении установленной версии). из источника). Затем переустановите любую версию, которую вы хотите иметь./usr/local/src/program-or-library-name

Что касается выполнения зависимостей:

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

    Аналогично, программное обеспечение по крайней мере попытается установить полностью, даже если вы вручную удалили файлы, предоставленные пакетами, от которых зависит устанавливаемое программное обеспечение. (Как правило, не следует пытаться использовать это для каких-либо целей. Менеджер пакетов, работающий на основе ложной информации, почти всегда является плохой вещью.)

Поэтому, если вы не можете найти пакет, содержащий нужную вам версию программного обеспечения, вам может потребоваться создать собственный .debпакет из скомпилированного вами программного обеспечения и установить его из этого пакета. Тогда менеджер пакетов узнает, что происходит. Создать пакет для собственного использования, который вам не нужен для работы на компьютерах других людей, на самом деле не очень сложно. (Но я чувствую, что это может выходить за рамки вашего вопроса, поскольку он в настоящее время сформулирован.)


Спасибо за ваш подробный ответ, он прояснил многие концепции
Филип Д'Розарио

5

То, что вы устанавливаете из центра программного обеспечения или с помощью команды APT ( apt-get, aptitude) или с помощью dpkg, известно системе управления пакетами. dpkgэто низкоуровневый инструмент управления пакетами, APT и его друзья - это высокоуровневые инструменты, которые вызывают dpkgдля выполнения фактической установки, а также обрабатывают зависимости и загрузки пакетов.

Если вы скомпилируете программу из исходного кода, она не будет известна менеджеру пакетов. Соглашение по Linux, которому вы должны следовать из-за того, что вам трудно следить за вещами и переопределять ваши установки:

  • /bin, /lib, /sbin, /usrЗарезервированы для менеджера пакетов;
  • за исключением того, что /usr/localэто для системного администратора - соблюдайте иерархию каталогов, но вы сами управляете файлами.

Смотрите лучший способ обновить vim / gvim до 7.3 в Ubuntu 10.04? для списка способов получить более свежие версии программного обеспечения. Самый простой способ - получить PPA , если он есть. Если вы получаете бинарный пакет или компиляцию из исходного кода, я рекомендую использовать stow для управления установленным вручную программным обеспечением. В качестве альтернативы, создайте свой собственный .debпакет - это больше работы, но оно окупается, если вы часто обновляетесь (обычно повторная установка пакета для следующей вспомогательной версии выполняется очень быстро) или если вы развертываете на многих машинах, работающих под одним и тем же дистрибутивом.

В большинстве программ, если вы запускаете ./configure && make && sudo make install, программа устанавливается в /usr/local. Проверьте документацию, поставляемую с источником (обычно в файле с именем READMEили INSTALL), или запустите, ./configure --helpчтобы убедиться, что это так. Если программа установлена ​​в /usr/local, она не будет мешать версии, предоставленной менеджером пакетов. /usr/local/binна первом месте в системе PATH. Обратите внимание, что вам нужно будет работать make installот имени администратора (root); не компилировать как root. Как отмечалось выше, я рекомендую использовать stow вместо установки непосредственно в /usr/local.


1

Это зависит от комплектации и многих других вещей

  1. используемые соглашения об именах - содержит ли двоичный файл номера версий в именах файлов
  2. место установки - это по умолчанию в opt, но упакованная версия находится в / usr
  3. много больше возможностей

Короче говоря:
нет общего ответа. Это сильно зависит от пакета. Вы должны использовать официальные +1 PPA, если это возможно, в отличие от компиляции из исходного кода.


1
На самом деле это довольно необычно для программ или библиотек, скомпилированных из исходного кода, для установки в /opt. /usr/localявляется стандартным префиксом, и даже /usrявляется более распространенным префиксом по умолчанию, чем /opt. /optчаще всего используется для программного обеспечения, которое устанавливается внутри выделенного каталога, названного для конкретного приложения (так, например, приложение с именем Foo может быть установлено со всеми его файлами внутри /opt/foo).
Элия ​​Каган
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.