yum оставляет зависимость от

Question

Моя проблема в том, что у меня есть пакет, содержащий несколько RPM, например rpmA, rpmB, rpmC. rpmC зависит от rpmA, и версии блокируются вместе, поэтому rpmC (v1) зависит от rpmA (v1).

Но пакет v2 имеет устаревший rpmC и содержит rpmA (v2) и rpmB (v2). Файл SPEC для rpmA (v2) указывает, что rpmC (v1) устарел, но я не могу заставить yum позволить мне перейти на v2 - кто-нибудь знает почему?

Какая yum, похоже, пытается обновить rpmA и rpmB, но затем она выдает ошибку, поскольку она не удаляет rpmC (v1), а rpmC (v1) требует rpmA (v1), который был удален и обновлен до РАПН (v2).

К сожалению, я не контролировал оригинальные RPM v1, поэтому я не могу, например, заставить rpmC (v1) зависеть от rpmA (> = v1), и я также не могу найти способ сделать yum let me выполните обновление.

Предложения по поводу того, что я могу делать неправильно?

Answer 1

В соответствии с комментариями проблема заключается в том, что каждый RPM неявно предоставляет как «функцию», так и «функцию (архитектуру)», например. 'ssl' и 'ssl (x86_64)'. Мои усталости явно включали архитектуру, поэтому только устаревшие (например,) ssl (x86_64) «оставляют» ssl для генерации нерешенных зависимостей.

Если вы удалите архитектуру из директивы obsoletes, то и «функция» и «функция (архитектура)» устарели, и все начинает работать.

Подведем итоги:

1. Использование Obsoletes, что один из оставшихся РПМ устаревшим РПС, что вы будете удалять как часть обновления
2. НЕ указать архитектуру в директивах Obsoletes так, что все экземпляры функции/RPM удаляются.
3. В то же время рассмотрите, требуют ли ваши директивы для указания конкретных версий зависимостей или используют> =, что может позволить работать над уровнем выше, - это тоже меня кусает!

Радость наследования определений RPM :-).