Как получить путь к файлу спецификации в файле спецификации об/мин
Вы можете заставить dpkg выполнить команду до или после операций управления пакетами. Передайте опцию - до вызова = КОМАНДА или - после вызова = КОМАНДА ; команда выполняется с переменной среды DPKG_HOOK_ACTION , установленной в соответствии с характером действия. Это не очень удобно, потому что эти хуки запускаются один раз при вызове dpkg , а не один раз для каждого пакета, и они не предоставляют способа узнать, что процесс dpkg будет делать или делал. . Косвенный способ узнать, что произошло, - это зарегистрировать состояние интересующего вас пакета (ов) до и после действия и вызвать ваше настраиваемое действие, если состояние изменилось. Вы также можете получить эту информацию, проанализировав журналы ( /var/log/dpkg.log ).
Более конкретным решением было бы подключиться к стандартному механизму, который Debian предоставляет для решения вашей проблемы. Пакет nginx (точнее nginx-light или nginx-full ) вызывает invoke-rc.d nginx start как часть своего сценарий post-install ( postinst ) и invoke-rc.d nginx stop как часть сценария предварительного удаления ( prerm ). Замените команду invoke-rc.d на команду, адаптированную для runit и вызывающей sv ; вы можете использовать для этого dpkg-divert :
dpkg-divert --add --rename --divert /usr/sbin/invoke-rc.d.sysvinit /usr/sbin/invoke-rc.d
ln -s invoke-rc.d.runit /usr/sbin/invoke-rc.d
В качестве альтернативы поместите свою собственную копию invoke-rc.d , адаптированную к sv раньше, чем / usr / sbin в пути, например в / usr / local / sbin .
Сценарий /usr/sbin/invoke-rc.d.runit или /usr/sbin/invoke-rc.d должен позаботиться о реализации вызова -rc.d интерфейс :
- Поддержка синтаксиса
invoke-rc.d СЕРВИС ДЕЙСТВИЕ, где ДЕЙСТВИЕ является одним изначало,остановить,перезапустить,принудительно перезагрузить,перезагрузить. - Поддержите параметр
- quiet(единственный, который, как я вижу, используется сценариями обслуживания пакетов в моей системе, я не провел исчерпывающий поиск всех пакетов Debian). - Вызовите
/usr/sbin/policy-rc.d, как описано на странице руководства, если вам это нужно (например,чтобы избежать запуска служб в chroot или контейнере).
Если вы хотите управлять только Nginx с помощью runit, запустите свой invoke-rc.d стандартный, если имя службы не nginx .
Учитывая все обстоятельства, если вы просто хотите управлять Nginx с помощью Runit, то перенаправление (или даже редактирование - это файл конфигурации) /etc/init.d/nginx кажется самым простым способом. Используйте существующий сценарий в качестве отправной точки и замените вызовы start-stop-daemon соответствующими вызовами nv .
Путь часто определяется самим процессом. Если вы посмотрите на результат процесса сборки, вы увидите, что он записывается в разные каталоги по мере подготовки к следующему этапу процесса.
Проще говоря, если вы измените абсолютные пути на относительный (и все ваши исходные файлы должны быть в полезной нагрузке вашего SRPM или перемещены в дерево исходных текстов перед сборкой, если это новая сборка), то большая часть этих проблем будет с радостью уходи.
Также, используя эхо в разделе% prepare, посмотрите на тупые уловки с домашними животными вроде
% prepare echo% (dirname% {Source0}) echo% (basename% { S: 1})
Когда вы абсолютно уверены, что вам обязательно нужно устроить такой ужастик, такой беспорядок вам пригодится. Если можете, сохраните это как раритет.
Кто-то лучше меня: если вы видите этот пост, напомните мне, как заставить его разрешать этот% () ТОЛЬКО один раз, а не каждый раз, когда это необходимо?
%{_specdir} /${name}.spec
выполнит работу. См. Эту страницу Fedora Wiki для получения дополнительной информации.