у меня есть breakfast пакет, который Requires toast, bacon, и eggs. Важно отметить, что breakfast нужен ровно один eggs реализация, чтобы быть сбалансированным питанием.
В scrambled-eggs пакет Provides eggs. Так делает fried-eggs пакет. Ни при каких обстоятельствах не следует scrambled-eggs быть установлен рядом fried-eggs, даже при отсутствии breakfast.
Если бы было только два способа приготовления яиц, решением было бы добавить Conflicts: fried-eggs к scrambled-eggs пакет и наоборот. Однако существует множество способов приготовления яиц, некоторые из которых еще даже не известны, а новый способ приготовления яиц может быть не знаком со всеми другими способами приготовления яиц.
Интересно, что для RPM версии 4.11.3 вы можете сделать так, чтобы каждый пакет имел оба Provides: eggs и Conflicts: eggs, но это поведение не задокументировано. Фактически, документация похоже, предполагает, что это не должно работать:
Конфликты в основном обратные Requires. Если есть подходящий пакет, его нельзя установить. Не имеет значения, находится ли тег Conflict: в уже установленном или устанавливаемом пакете.
Могу ли я полагаться на описанное выше поведение Provides / Conflicts для будущих версий RPM? Или как еще решить эту проблему?
Простой ответ:
Дело не в «функциональности».
«Предоставляет» - обычно перечисляет, какие файлы предоставляются (полный путь) и «теги» (тост, бекон, яйцо) включены. «Теги» (давайте интерпретируем это так) ДОЛЖНЫ быть уникальными для чего-то очень конкретного, а не для функциональности, такой как MTA или так.
Возникают конфликты, когда несколько версий пакетов с одинаковым именем не разрешены или совпадают «Предоставляет».
По сути, вам НЕ СЛЕДУЕТ интерпретировать «предоставляет» как «функциональность». Это идея.