Кто-нибудь знает, как (или можно ли) указать альтернативное требование или набор требований в файле спецификации, в отличие от одного требования?
Например, скажем, есть два доступных пакета, с удобным названием foo-barи bar-foo. Мой пакет требует одного из них, но не обоих, и мне все равно, какой из них присутствует. Во время выполнения я использую то, что доступно.
Так эффективно я хотел бы сказать:
Requires: foo-bar OR bar-foo
Насколько я могу судить, это невозможно, но я полагаю, что здесь есть люди, которые знают о RPM намного больше, чем я, поэтому, возможно, есть способ сделать это.
ОБНОВЛЕНИЕ: я только контролирую упаковку bar-foo, не foo-barтак, так что оба предоставляют виртуальный пакет не будет работать.
ОБНОВЛЕНИЕ: Что мне действительно нужно, так это виртуальный пакет внутри каждого из пакетов. Скажем, foo-bar provides eagle' andbar-foo предоставляет beagle and my package works with either (or both); but other packages require eithereagle orbeagle orfoo-bar orbar-foo`, и в целевой системе может быть установлен один или оба.
В настоящее время я склоняюсь к решению этого с помощью %preскрипта, который делает что-то вроде:
rpm -q eagle || rpm -q beagle || echo "need eagle or beagle" && /bin/false
Хотя я почти уверен, что это сработает, это похоже на жестокое обход отслеживания зависимостей RPM. Например, вы никогда не увидите мою посылку, когда спросите whatrequires foo-barили whatrequires beagle.
ОБНОВЛЕНИЕ: если подумать, боль от необходимости устанавливать людей foo-barтам, где они могут, не меньше, чем боль от обхода управления зависимостями RPM, по крайней мере, для моей ситуации. Так что, если кто-то не придумает способ должным образом потребовать «это ИЛИ» (что, я думаю, было бы отличной возможностью иметь в RPM в целом), тогда я планирую требовать только этого, foo-bar а затем, во время выполнения, если bar-fooдоступно, я буду выбирать между их по любым критериям, которые мне нужны.
ОБНОВЛЕНИЕ: другая идея, которая также будет обманывать RPM, но может привести вещи в правильное состояние. Может быть, я мог бы %postнапрямую поиграть с базой данных RPM. Таким образом , %preможет защитить меня от недопустимой установки, и %postбудет задним числом сказать RPM , что я требую либо foo-barили bar-fooили оба, в зависимости от того, что там при установке.
Спасибо за предложения!
Provides: foo-bar, чтобы он удовлетворял обеим зависимостям. Для более новых версий rpm проверьте Boolean Dependencies . Держитесь подальше от%preи%postучастков, не пытайтесь победить систему .Ответы:
Теперь это возможно с RPM 4.13.
https://rpm.org/user_doc/boolean_dependencies.html
Это может быть просто, как:
Requires: (pkgA >= 3.2 or pkgB)источник
Такое поведение уже выполняется несколькими пакетами, например почтовыми транспортными агентами. Эти виртуальные пакеты предоставляют вашей системе способ узнать, предоставляется ли им необходимая возможность какой-либо другой программой.
Посмотрите, поможет ли вам пример виртуальных пакетов в rpm.org.
источник
foo-barиbar-foo, и, так как я не контролирую упаковку,foo-barя не могу просто заставить их обоих предоставлятьsupport-for-mypackage. Если бы я контролировал упаковку обеих альтернативных предпосылок, то действительно виртуальный пакет был бы отличным решением.Две возможности:
Если часть
foo-barиbar-fooвы используете общий файл, вы можете простоRequire /path/to/file(я так думаю ; мое тестирование было ограничено).Ваша ситуация похожа на необязательные зависимости. Способ, которым они обрабатываются, состоит в том, чтобы иметь
X-commonпакет, а затем иметьX-foo-barпакет, который требует,foo-barиX-bar-fooпакет, который требуетbar-foo.источник
foo-barмогла бы перемещать свои файлы (я управляю толькоbar-fooздесь). Необязательные зависимости интересны , но не совсем то , что мне нужно, так как я действительно нужно либоfoo-barилиbar-foo; единственное, что необязательно, это выбор которого. Спасибо за ответ.Require: /usr/bin/python3Сработает ли для вас, чтобы ваш пакет bar-foo предоставлял виртуальный пакет foo-bar?
Затем вы можете просто сделать ваш пакет burp-baz требующим foo-bar.
Если при выполнении вышеперечисленных действий вы чувствуете себя скептически (возможно, так и есть), вам может понадобиться создать две версии RPM, одну в зависимости,
foo-barа другую в зависимостиbar-foo.источник
foo-bar, сломалось бы, если бы оно считало,bar-fooчто оно предоставляет то, чего в действительности не было. Камнем преткновения является то, что для моей посылки мне нужны либо предварительные условия, но не оба; но любой другой пакет может действительно нуждаться только в одном из них. И я не могу просто требовать и того и другого, поскольку есть реальные случаи, когда будет доступен только один или другой.Недетерминизм в автоматизированных системах (будь то управление зависимостями или машины, использующие RPM) - это действительно плохо. Вы ХОТИТЕ потерпеть неудачу в той или иной ситуации, поскольку неудача все же не так плоха, как неожиданный результат.
Чтобы решить эту проблему, возможно, попросите пакет, который вы ДЕЛАЕТЕ контролировать%, предоставить основные токены, которые также предоставляется неизменным пакетом% и от которого зависит ваш другой программный%; тогда ваш пакет% устарел неизменным. Особенно, если он уже на месте, вы можете выиграть его над другой установкой.
Упаковка и правильная зависимость и установка - сложная работа. Цель - надежные, повторяемые, проверяемые установки - настолько ценна, что вы можете понять выгоды от ее правильного выполнения.
Зависимость ада наносится самому себе. Без исключений
источник