Я пишу несколько RPM, которые устанавливают файлы конфигурации репозитория YUM для различных внутренних репозиториев YUM, с той же структурой и концепцией, что и RPM репозитория EPEL.
У нас будет несколько сред с эквивалентными репозиториями, поэтому мы используем плагин приоритетов yum, чтобы гарантировать, что репозитории среды, расположенные на более ранней стадии развертывания (например, QA), имеют приоритет над теми, которые появятся позже (например, производственные). Мы также реплицируем версии CentOS, которые мы используем, на внутреннем зеркале. У нас есть вся эта работа, включая публикацию этих RPM конфигурации репозитория, но остается один особый случай, когда я хотел бы получить совет по наилучшему способу решения проблемы дизайна.
И это так: файл конфигурации базового репозитория CentOS /etc/yum.repos.d/CentOS-Base.repo принадлежит RPM-пакету centos-release, поэтому я не могу перезаписать его в моем собственном RPM без замены этого системного RPM, чего я не хочу делать. Но мне нужно внести некоторые изменения в этот файл, чтобы он работал с описанным выше дизайном. В каждом разделе репо
Мне нужно изменить эти строки:
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
К этим строкам:
mirrorlist=http://mirrorlist.MYCOMPANY.com/?platform=centos&release=$releasever&arch=$basearch&repo=os #baseurl=http://mirror.MYCOMPANY.com/centos/$releasever/os/$basearch/
priority=2
В настоящее время я создаю RPM, который устанавливает /etc/yum.repos.d/CentOS-Base-pr.repo, затем в сообщении% он переименовывает существующий CentOS-Base.repo в CentOS-Base.repo.orig, затем переименовывает новый CentOS-Base-pr.repo в CentOS-Base.repo. В% postun он отменяет это, чтобы восстановить исходный файл. Я чувствую, что это работает, но это немного путаница.
Вместо этого я бы хотел не устанавливать файлы, а запустить сценарий sed, чтобы внести эти изменения в исходный файл CentOS-Base.repo в% post, и другой сценарий sed, чтобы отменить изменения в% postun. Это позволяет мне обрабатывать установку / удаление всех наших пользовательских репозиториев одинаково, с одинаковым результатом как для существующих, так и для новых репозиториев.
Я не знаю, является ли это допустимым или рекомендуемым подходом, когда вы пытаетесь внести изменения в конфигурацию этого типа для существующих файлов, установленных другими RPM?
Прежде чем я получу ответы на этот вопрос, мы используем Chef для большинства пост-конфигураций RPM, аналогичных этой, но не хотим использовать это в этом случае, поскольку мы не хотим иметь особый случай для конфигурации репо в только этот один экземпляр, и мы пытаемся использовать RPM для инкапсуляции "тяжелой" логики установки / обновления внутри RPM в другом месте. Мы хотим, чтобы наше собственное программное обеспечение вело себя как другое программное обеспечение с открытым исходным кодом, поскольку оно может устанавливаться и запускаться без зависимости от Chef для базовой установки, а Chef используется только для настройки (т.е. как Chef настраивает nginx или tomcat).
Спасибо заранее за любые советы...
Можно использовать скрипт сам по себе или скрипт, встроенный в rpm, если вы так предпочитаете. Мне нравится идея использования пустых или мета-RPM для создания собственных виртуальных групп или выполнения определенных задач. В этом случае я был бы обеспокоен тем, что более поздний пакет centos-release снесет мои изменения. Было бы проще отслеживать это, если бы в вашем пакете был файл, который вы хотели, и вы установили его с --replacefiles вариант.