Чи можна вимагати пакет "цей АБО той" у специфікаційному файлі RPM?

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

Наприклад, скажімо, що доступні два пакети, зручно названі foo-barта bar-foo. Мій пакунок вимагає одного з цих, але не обох, і мені все одно, який з них є. Під час виконання я використовую те, що є в наявності.

Настільки ефективно я хотів би сказати:

Requires: foo-bar OR bar-foo

Наскільки я можу сказати, це неможливо, але я вважаю, що тут є люди, які знають про RPM набагато більше, ніж я, тому, можливо, є спосіб це зробити.

ОНОВЛЕННЯ: Я контролюю лише упаковку bar-foo, ні foo-bar, тому надання обох віртуальних пакетів не буде працювати.

ОНОВЛЕННЯ: Те, що мені насправді потрібно, - це сам віртуальний пакет у кожному з пакетів. Скажімо, foo-bar provides eagle' andbar-foo забезпечує бігль- and my package works with either (or both); but other packages require eitherорел 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 4.13.

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

Це може бути просто, як: Requires: (pkgA >= 3.2 or pkgB)

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

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

Дві можливості:

Якщо частина foo-barта bar-fooви використовуєте загальний файл, ви можете просто Require /path/to/file(я думаю, що так, моє тестування було обмеженим).

Ваша ситуація схожа на факультативні залежності. Спосіб, яким вони займаються, - це мати X-commonпакунок, а потім мати необхідний X-foo-barпакет foo-barта необхідний X-bar-fooпакет bar-foo.

Чи буде працювати для вас, щоб ваш пакет bar-foo надав віртуальний пакет foo-bar?

Тоді ви можете просто зробити так, щоб ваш пакет відриг-баз вимагав колонтитула.

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

Щоб вирішити проблему, можливо, у пакеті, який ви контролюєте,% надаються основні жетони, від яких також надається незмінний пакет%, і від якого залежить ваше інше програмне забезпечення%; тоді ваш пакунок% застаріває незмінний. Особливо, якщо він вже встановлений, ви можете виграти його над іншою установкою.

Упаковка та належна залежність та операції встановлення - це хитра робота. Мета - надійні, повторювані, перевірені встановлення - настільки цінна, що ви можете усвідомити користь від її правильного.

Пекло залежності залежно від себе. Немає винятків