Можно ли требовать пакет «это или это» в файле спецификации RPM?

30

Кто-нибудь знает, как (или можно ли) указать альтернативное требование или набор требований в файле спецификации, в отличие от одного требования?

Например, скажем, есть два доступных пакета, с удобным названием 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или оба, в зависимости от того, что там при установке.

Спасибо за предложения!

rpm

— Кевин Фрост
источник

Я знаю, что это очень старый; но есть ли хорошее решение для этого сейчас? Я делаю RPM с java-1.6.0-openjdk в Требуется: линия; но с java7; Я также хотел бы поддержать java-1.7.0-openjdk, но не мог найти хороший способ поместить любой из этих двух в Требует:

— vpram86

Если вы управляете упаковкой bar-foo, одним из возможных решений является его сборка Provides: foo-bar, чтобы он удовлетворял обеим зависимостям. Для более новых версий rpm проверьте Boolean Dependencies . Держитесь подальше от %preи %postучастков, не пытайтесь победить систему .

— forcefsck

13

Теперь это возможно с RPM 4.13.

https://rpm.org/user_doc/boolean_dependencies.html

Это может быть просто, как: Requires: (pkgA >= 3.2 or pkgB)

— carlwgeorge
источник

Исходя из документа, похоже, что их нельзя использовать с require, только «слабые» зависимости верны?

— dsollen

Вторая ссылка показывает, что они могут быть использованы с Требуется. В первой ссылке упоминается, что такое использование запрещено в Fedora, но это не относится к пользовательским пакетам.

— Carlwgeorge

9

Такое поведение уже выполняется несколькими пакетами, например почтовыми транспортными агентами. Эти виртуальные пакеты предоставляют вашей системе способ узнать, предоставляется ли им необходимая возможность какой-либо другой программой.

Посмотрите, поможет ли вам пример виртуальных пакетов в rpm.org.

— Янне Пиккарайнен
источник

Спасибо. Я не думаю, что виртуальные пакеты решат мою конкретную проблему здесь, но я согласен, что они очень полезны. В моем случае я не хочу требовать какой-то общей функции, предоставляемой обоими foo-barи bar-foo, и, так как я не контролирую упаковку, foo-barя не могу просто заставить их обоих предоставлять support-for-mypackage. Если бы я контролировал упаковку обеих альтернативных предпосылок, то действительно виртуальный пакет был бы отличным решением.

— Кевин Фрост

5

Две возможности:

Если часть 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 ; единственное, что необязательно, это выбор которого. Спасибо за ответ.

— Кевин Фрост

Это решило мою проблему! Различные варианты GNU / Linux предоставляют разные виртуальные пакеты python3: python3, python34, python35 и т. Д. Чтобы мой единый пакет работал на всех них, я смог просто использоватьRequire: /usr/bin/python3

— bgStack15

0

Сработает ли для вас, чтобы ваш пакет bar-foo предоставлял виртуальный пакет foo-bar?

Затем вы можете просто сделать ваш пакет burp-baz требующим foo-bar.

Если при выполнении вышеперечисленных действий вы чувствуете себя скептически (возможно, так и есть), вам может понадобиться создать две версии RPM, одну в зависимости, foo-barа другую в зависимости bar-foo.

— MikeyB
источник

Заманчиво, но опасно: что-то еще, что действительно нужно foo-bar, сломалось бы, если бы оно считало, bar-fooчто оно предоставляет то, чего в действительности не было. Камнем преткновения является то, что для моей посылки мне нужны либо предварительные условия, но не оба; но любой другой пакет может действительно нуждаться только в одном из них. И я не могу просто требовать и того и другого, поскольку есть реальные случаи, когда будет доступен только один или другой.

— Кевин Фрост

-2

Недетерминизм в автоматизированных системах (будь то управление зависимостями или машины, использующие RPM) - это действительно плохо. Вы ХОТИТЕ потерпеть неудачу в той или иной ситуации, поскольку неудача все же не так плоха, как неожиданный результат.

Чтобы решить эту проблему, возможно, попросите пакет, который вы ДЕЛАЕТЕ контролировать%, предоставить основные токены, которые также предоставляется неизменным пакетом% и от которого зависит ваш другой программный%; тогда ваш пакет% устарел неизменным. Особенно, если он уже на месте, вы можете выиграть его над другой установкой.

Упаковка и правильная зависимость и установка - сложная работа. Цель - надежные, повторяемые, проверяемые установки - настолько ценна, что вы можете понять выгоды от ее правильного выполнения.

Зависимость ада наносится самому себе. Без исключений

— user2066657
источник

Вот рыба, которую я дам вам: вам нужен только один из двух, потому что оба предоставляют некоторый файл или ресурс. Таким образом,% не зависит от имени пакета, только от файла или ресурса, который они предоставляют. Да, вы все равно будете ухаживать за недетерминизмом, но если вы на самом деле рассматриваете возможность взлома напрямую с rpmdb, вы уже с радостью рассматриваете риски, которых большинство людей научились избегать. Я надеюсь, что вы можете найти решение, которое не несет такой технической задолженности.

— user2066657