Установка двоичных файлов в /bin, /sbin, /usr/bin и /usr/sbin, взаимодействие с --prefix и DESTDIR

Большинство пакетов, использующих Autotools, являются утилитами уровня пользователя или, по крайней мере, достаточно высокого уровня, чтобы быть полностью ниже /usr, или достаточно низкого, чтобы быть полностью ниже /usr.

Я пишу пакет, который должен установить некоторые файлы в /bin, некоторые в /sbin, /usr/bin и /usr/sbin. Он заменяет несколько существующих двоичных файлов, которые традиционно размещаются в этих местах.

Также необходимо установить модуль PAM в /lib/security (и, очевидно, /usr/lib/security не сработает).

Теперь проблема в том, что префикс конфигурации по умолчанию выглядит как /usr/local. Я могу управлять этим значением по умолчанию в моем файле configure.ac. По крайней мере, в Gentoo Linux по умолчанию стоит --prefix=/usr. Это проблема, потому что она переопределяет любые значения по умолчанию, которые я указал в своем configure.ac.

Я кратко рассмотрел, как другие подобные пакеты справляются с этой проблемой. Вот мои выводы:

  • bash-4.1, кажется, устанавливается в /usr/bin, а скрипты сборки дистрибутива перемещают двоичный файл bash в /bin
  • Linux-PAM имеет хаки в configure.ac, так что если префикс /usr, он будет использовать /sbin и /lib для некоторых своих файлов. Он также устанавливает префикс по умолчанию /usr. Я не уверен, что произойдет, если пользователь передаст другой --prefix.
  • shadow-utils установите exec_prefix на "", если префикс /usr. Затем bin_PROGRAMS ссылается на /bin, а ubindir объявляется указателем на ${prefix}/bin, так что ubin_PROGRAMS ссылается на /usr/bin.

Мои вопросы:

  • Каковы значения по умолчанию для --prefix в других дистрибутивах? Могу ли я разумно предположить, что это всегда /usr? На данный момент меня интересует только Linux, а не BSD.
  • Какое из приведенных выше решений кажется самым чистым? Вы видите лучшие решения?
  • Каковы потенциальные проблемы с вышеуказанными решениями? Есть ли какие-то решения этих проблем?
  • Я в порядке с установкой всего в /bin и созданием символических ссылок совместимости. Делает ли это проблему проще?
  • Существует ли какая-либо другая общая система сборки, приемлемая для низкоуровневых системных утилит, которая лучше соответствовала бы моим требованиям?

Не стесняйтесь просить разъяснения того, что я пытаюсь сделать. Обратите внимание, что если я хочу сохранить совместимость с тем, что я заменяю, если раньше поставлялись двоичные файлы A и B, один в /sbin и один в /usr/bin, я думаю, что мне просто нужно поставить замены в этих местах или, по крайней мере, иметь символические ссылки. Модули PAM также имеют фиксированное место установки.

Очевидно, что я поддержу любой полезный ответ. Я «принятый ответ». Я в основном ищу совет «что мне делать», какое самое чистое решение проблемы и, если применимо, обсуждение вариантов и недостатков, плюсов и минусов.


linux autotools makefile pam autoconf
person Paweł Hajdan    schedule 29.12.2011    source источник
comment
Вы не должны изменять значение по умолчанию в файле configure.ac. Если пользователь запускает ваш скрипт configure без назначения префикса, пользователь имеет полное право ожидать /usr/local по умолчанию. Если вы измените это, у вас будет ошибка упаковки. Установка префикса является правом (и обязанностью) пользователя, и сопровождающий пакета не имеет права даже беспокоиться об этом.   -  person William Pursell    schedule 29.12.2011
comment
Вы можете установить --prefix в файле .spec или в debian/rules, но вы абсолютно не должны изменять его в configure.ac   -  person William Pursell    schedule 29.12.2011

Ответы (2)


arrow_upward
4
arrow_downward

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

Для обоснования предположим, что кто-то пытается создать среду chroot. Различие между /usr и / не имеет смысла в среде и не будет проводиться. Все префиксы установлены на /foo/bar/chroot, и любой скрипт конфигурации, использующий $prefix, скорее всего, вызовет странное поведение. Те же аргументы применимы и к сценариям, таким как помощники по упаковке Debian, которые полагаются на обычную семантику $prefix для работы.

Таким образом, самым чистым раствором является раствор bash-4.1. По сути, у вас есть два чистых варианта: разделить ваш пакет на критические для загрузки и некритические для загрузки части или позволить вашему сценарию configure предлагать альтернативный префикс для критически важных для загрузки частей, который по умолчанию установлен на /, оставив $prefix как /usr. .

person thiton    schedule 29.12.2011
comment
Мне нравится это разделение на критичные для загрузки и некритичные для загрузки части, но не беспокойтесь о значениях по умолчанию. Сделайте их двумя отдельными пакетами, и тогда ebuild сможет вызывать econf --prefix=/ или что-то в этом роде. - person Jack Kelly; 03.01.2012

arrow_upward
3
arrow_downward

У этого вопроса есть два разных уровня, и все ваши вопросы, кажется, относятся ко второму значению (бинарный пакет, сгенерированный вашим файлом *.spec, или файлом debian/rules, или файлом *.pkg). обеспокоены, вам НЕ НУЖНО. Вы не должны пытаться указать в файле configure.ac префикс по умолчанию, отличный от /usr/local. Указание того, куда что следует установить, выполняется в управляющих файлах бинарных пакетов, а НЕ в configure.ac. Исходный дистрибутив, использующий скрипт configure, сгенерированный autoconf, должен по умолчанию устанавливаться в /usr/local, а все остальное является ошибкой упаковки.

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

#!/bin/sh

case $1 in
foo) args='--prefix=/usr --bindir=/bin --sysconfdir=/etc';;
bar) args='--prefix=/opt';;
*) args=;;
esac
$(dirname $0)/configure $args &&
make &&
make install

в котором будут указаны аргументы по умолчанию для настройки для платформ «foo» и «bar», но на самом деле похоже, что ваши вопросы касаются управляющих файлов для двоичных пакетов.

person William Pursell    schedule 29.12.2011