если симлинк указывает на файл в "за-альтернатированной" директории например, xxx -> /usr/lib/jvm/java//jre/lib/rt.jar где /usr/lib/jvm/java/ -- альтернатива то ставится зависимость на конкретный rt.jar (например, на java-1.4.2-sun) что порождает unmet на x86_64. нужно ставить зависимость на альтернативу /usr/lib/jvm/java /usr/lib/jvm/java -> /etc/alternatives ... т. е. надо после чтения симлинка по циклу пройти по его каталогам, не является ли подпуть ссылкой куда-то в /etc/alternatives. Steps to Reproduce: 1. 2. .
То есть при разрешении симлинка выясняется, что один из промежуточных катаологов в свою очередь опять является симлинком, который висит на альтернативах. Очень шаткая конструкция. В любом случае, то что Вы предлагаете, если я правильно понимаю, в этом случае какая бы то ни была зависимоть на rt.jar потеряется. Зависимость на /usr/lib/jvm/java не гарантирует, что где-то под этим каталогом будет лажать rt.jar. Конкретная зависимость лучше никакой, потому что она гарантерует что файл rt.jar будет на месте. Надо подумать...
> Конкретная зависимость лучше никакой, потому что она гарантерует что файл rt.jar > будет на месте. Конкретная зависимость хуже никакой. Этот баг родился из реальной сборки пакета. Подчеркну, что она не гарантирует, что файл rt.jar будет на месте.-- Зависимость то ставится не на rt.jar, а на java-1.4.2-sun, если сборке случилось быть на ix86 это 1) порождает unmet на x86_64, 2) ix86 unmet не будет, но вытянется 40MB ненужного мусора (java-1.4.2-sun) да и вообще по смыслу там должна быть зависимость на виртуальный пакет java.
Хорошо. Я понимаю, что "правильную" (необходимой и достаточную) зависимость здесь указать очень сложно. Я попробую реализовать в symlinks.req проверку на прохождение пути через альтернативы. Текущий workaround -- %add_findreq_skiplit /path/to/symlink Прошу его использовать только в случае реальной необходимости, т.к. symlinks.req отлавливает гораздо больше настоящих ошибок запаковки, нежели чем производит "каверзных" зависимостей.
> Прошу его использовать только в случае реальной необходимости, т.к. symlinks.req > отлавливает гораздо больше настоящих ошибок запаковки, нежели чем производит > "каверзных" зависимостей. Да, вещь хорошая.
Вы не написали, как нызвается пакет, в котором symlinks.req даёт слишком конкретную зависимость. У меня сейчас есть немного времени, чтобы это дело поковырять, но я уже трачу его на поиски подходящего пакета, чтобы обдумать что к чему.
например maven-1.1. В нем сейчас стоит AutoReq: yes,nosymlinks если убрать должно воспроизвестись если не ошибаюсь с /usr/lib/jvm/java//jre/lib/tools.jar
Проблема очень плохая. Есть примеры из базовой системы гораздо проще -- напр. /usr/share/libtool. У меня сейчас закипят мозги, потому что я не знаю, как наиболее правильно сделать для всех возможных случаев. $ sh -efu -c '. /usr/lib/rpm/find-package; FindPackage foo /usr/share/libtool' /usr/share/libtool $ sh -efu -c '. /usr/lib/rpm/find-package; FindPackage foo /usr/share/libtool/' sh: foo: checking contents_index_all for /usr/share/libtool-1.5 sh: foo: /usr/share/libtool-1.5 -> libtool_1.5 (via contents_index_all) libtool_1.5 $ sh -efu -c '. /usr/lib/rpm/find-package; FindPackage foo /usr/share/../share/libtool' /usr/share/../share/libtool $ Нужно очень осторожно пробовать каноникализировать пути в несколько заходов и смотреть, нет ли там ГДЕ-НИБУДЬ альтернатив. Причем тут есть разные варианты каноникализации. Например если разрешать путь /usr/share/libtool/../../bin/perl то вместо зависимости на /usr/bin/perl мы можем получить зависимость на /usr/share/libtool!
гм. в случае с /usr/share/libtool/../../bin/perl /usr/bin/perl (разрешение симлинка) и /usr/share/libtool (альтернатива) принадлежат разным пакетам. В этом случае имеет смысл выдать предупреждение, а зависимость ставить на /usr/bin/perl (как было раньше) либо вообще не ставить. если же (разрешение симлинка) и (альтернатива) предоставляются одим и тем же пакетом, то зависимость нужно ставить не на этот пакет, а на альтернативу, которую он предоставляет.
Хочу на всякий случай заметить, что проблема не специфична для symlinks.req. Речь идёт об общих принципах разрешения путей в зависимости.
Кажется, несмотря на кипение головы, все проблемы с альтернативами таки удалось решить. Прошу посмотреть 4.0.4-alt80-2-g2bf12ba (а также предыдущий коммит).
хорошо.
This was fixed in 4.0.4-alt81.
