GNU Autotools: установка двоичных файлов в / bin, / sbin, / usr / bin и / usr / sbin, взаимодействие с --prefix и DESTDIR - PullRequest
Новая
       42

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

6 голосов
/ 29 декабря 2011

Большинство пакетов, использующих автоинструменты, являются утилитами пользовательского уровня или, по крайней мере, достаточно высокого уровня, чтобы быть полностью в / 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, а скрипты сборки distro перемещают двоичный файл 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 также имеют фиксированное место установки.

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

Ответы [ 2 ]

3 голосов
/ 29 декабря 2011

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

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

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

2 голосов
/ 29 декабря 2011

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

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

#!/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', но на самом деле звучит так, будто ваши вопросы оуправляющие файлы для бинарных пакетов.

...