Как переопределить CONFIG_SITE в файле спецификаций (рекомендуемая практика)

Если пользователь, пытающийся собрать rpm из spec-файла, установил CONFIG_SITE в среде при запуске rpmbuild, а spec-файл строится с помощью «./configure --prefix=/usr && make», то пользовательские настройки в CONFIG_SITE могут полностью исказить сборка. (В качестве конкретного примера предположим, что /usr/share/config.site имеет строку «prefix=/bar». Тогда манифест файла спецификации будет совершенно неправильным, и rpmbuild завершится ошибкой.)

Какова наилучшая практика решения этой проблемы? Кажется, что обычная практика - игнорировать это. Я решил установить CONFIG_SITE=true в specfile:

CONFIG_SITE=true ./configure --prefix=/usr ...

При вызове rpmbuild чаще предполагается нетронутая среда и что нет такой глупости, как сброс префикса в /usr/share/config.site? Или мейнтейнер отвечает за то, чтобы файл спецификаций собирал rpm, как и ожидалось?


linux rpm autoconf rpm-spec
person William Pursell    schedule 26.05.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, если пользователи установили дурацкий файл config.site, это их собственная вина. Помимо этого, существует бесчисленное множество других способов вывести систему из строя; Я бы не беспокоился об этом. Я никогда не видел сценария сборки rpm или deb, который беспокоился бы об этом. Так что, возможно, это ваша «лучшая практика».

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

person Peter Eisentraut    schedule 29.05.2011
comment
Это их собственная ошибка ... источником вопроса была синтаксическая ошибка в моем $ HOME / config.site, из-за которой префикс всегда устанавливался на дочерний элемент $ HOME. Конечно, это моя вина, но то, что мои сборки терпят неудачу, очень сбивает с толку. - person William Pursell; 01.06.2011