RPM и мягкие зависимости
Опубликовано 20.2.2014 18:55 пользователем Peter Lemenkov
Weak-dependencies в RPM всегда были предметом дискуссии. Удивительно, но очень мало тех, кто однозначно сможет сказать, поддерживались ли директивы Recommends/Suggests/Supplements/Enhances в RPM. Некоторые дистрибутивы включали поддержку с помощью дистроспецифичных патчей, а в upstream была лишь поддержка на уровне распознавания директив в spec-файле. Дискуссии периодически возникали, и появлялись новые патчи, но рабочую поддержку чего-либо, кроме PRCO (Provides, Requires, Conflicts, Obsoletes) в upstream RPM так и не включили, посчитав вредной функциональностью.
Недавно сформулировали планы по управлению пакетами с помощью RPM на ближайшие пять лет, и среди планов появились сложные зависимости (как мягкие, так и вычисляемые во время установки). Похоже, что взгляды upstream-разработчиков претерпели изменения, и мягкие зависимости вновь появились в списке TODO.
Прошло несколько месяцев, и один из разработчиков RPM, наш коллега, Florian Festi, анонсировал новое появление мягких и вычисляемых зависимостей в RPM. Вновь появятся Recommends/Suggests/Supplements/Enhances, которые частично уже используются в SuSE Linux и некоторых других RPM-based дистрибутивах. После консультаций с Michael Schröder из SuSE было решено не использовать уже готовый вариант, а переписать все заново. Florian предполагает, что старые версии rpm и rpm-build просто будут игнорировать новые, неизвестные им тэги, но, к сожалению, он ошибается. Проверив вариант с нестандартным тэгом VCS, мы можем его заверить, что работать со старыми версиями RPM оно вряд-ли будет, потому что старый rpm-build скорее всего будет вываливаться с ошибкой. Если свою локальную копию rpm-build еще можно пропатчить или донастроить, то ожидать того, что в билд-сервисах будут доступны пропатченные версии утилит, это довольно самонадеянно. Причем "старые версии" в данном контексте означает, например, RHEL6 или Fedora 12. Но даже если это изменение можно как-то бэкпортировать в rpm-build, например заставив его игнорировать неизвестные тэги, то в любом случае совместимость будет полностью поломана следующим новшеством - вычисляемые зависимости (пока лишь содержащие логические выражения в Requires / Conflicts). По-простому бэкпортировать это уже сходу не получится.
Архитектурно, изменения не предназначены для самого комплекта утилит RPM. Задумано так, что новые директивы будут обрабатываться на уровне выше - Yum/DNF, и дело RPM лишь корректно записать тэги при сборке, и выставить их в API, если кто запросит. Но пока необходимый минимум утилит, т.е. библиотека libsolv, утилита createrepo, и rpm-build, еще не обрабатывают новые теги. Работа, конечно, уже ведется, но пока использовать новые тэги не рекомендуется, если вы не разработчик. А если вы разработчик приложений на базе API RPM, например, разрабатывающий альтернативный solver зависимостей, то Florian настоятельно рекомендует пообщаться с ними.
Недавно сформулировали планы по управлению пакетами с помощью RPM на ближайшие пять лет, и среди планов появились сложные зависимости (как мягкие, так и вычисляемые во время установки). Похоже, что взгляды upstream-разработчиков претерпели изменения, и мягкие зависимости вновь появились в списке TODO.
Прошло несколько месяцев, и один из разработчиков RPM, наш коллега, Florian Festi, анонсировал новое появление мягких и вычисляемых зависимостей в RPM. Вновь появятся Recommends/Suggests/Supplements/Enhances, которые частично уже используются в SuSE Linux и некоторых других RPM-based дистрибутивах. После консультаций с Michael Schröder из SuSE было решено не использовать уже готовый вариант, а переписать все заново. Florian предполагает, что старые версии rpm и rpm-build просто будут игнорировать новые, неизвестные им тэги, но, к сожалению, он ошибается. Проверив вариант с нестандартным тэгом VCS, мы можем его заверить, что работать со старыми версиями RPM оно вряд-ли будет, потому что старый rpm-build скорее всего будет вываливаться с ошибкой. Если свою локальную копию rpm-build еще можно пропатчить или донастроить, то ожидать того, что в билд-сервисах будут доступны пропатченные версии утилит, это довольно самонадеянно. Причем "старые версии" в данном контексте означает, например, RHEL6 или Fedora 12. Но даже если это изменение можно как-то бэкпортировать в rpm-build, например заставив его игнорировать неизвестные тэги, то в любом случае совместимость будет полностью поломана следующим новшеством - вычисляемые зависимости (пока лишь содержащие логические выражения в Requires / Conflicts). По-простому бэкпортировать это уже сходу не получится.
Архитектурно, изменения не предназначены для самого комплекта утилит RPM. Задумано так, что новые директивы будут обрабатываться на уровне выше - Yum/DNF, и дело RPM лишь корректно записать тэги при сборке, и выставить их в API, если кто запросит. Но пока необходимый минимум утилит, т.е. библиотека libsolv, утилита createrepo, и rpm-build, еще не обрабатывают новые теги. Работа, конечно, уже ведется, но пока использовать новые тэги не рекомендуется, если вы не разработчик. А если вы разработчик приложений на базе API RPM, например, разрабатывающий альтернативный solver зависимостей, то Florian настоятельно рекомендует пообщаться с ними.