13374 2007-11-09 19:44:17 +0300 symlinks.req should test alternatives in path 2008-04-23 11:47:24 +0400 1 1 4 Development Sisyphus rpm-build unstable all Linux CLOSED FIXED P2 normal --- 1 viy placeholder arseny glebfm imz ldv placeholder vt qa-sisyphus oldest_to_newest 57756 0 viy 2007-11-09 19:44:18 +0300 если симлинк указывает на файл в "за-альтернатированной" директории например, 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. . 57767 1 at 2007-11-10 00:38:33 +0300 То есть при разрешении симлинка выясняется, что один из промежуточных катаологов в свою очередь опять является симлинком, который висит на альтернативах. Очень шаткая конструкция. В любом случае, то что Вы предлагаете, если я правильно понимаю, в этом случае какая бы то ни была зависимоть на rt.jar потеряется. Зависимость на /usr/lib/jvm/java не гарантирует, что где-то под этим каталогом будет лажать rt.jar. Конкретная зависимость лучше никакой, потому что она гарантерует что файл rt.jar будет на месте. Надо подумать... 58142 2 viy 2007-11-13 17:26:22 +0300 > Конкретная зависимость лучше никакой, потому что она гарантерует что файл 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. 58151 3 at 2007-11-13 21:12:41 +0300 Хорошо. Я понимаю, что "правильную" (необходимой и достаточную) зависимость здесь указать очень сложно. Я попробую реализовать в symlinks.req проверку на прохождение пути через альтернативы. Текущий workaround -- %add_findreq_skiplit /path/to/symlink Прошу его использовать только в случае реальной необходимости, т.к. symlinks.req отлавливает гораздо больше настоящих ошибок запаковки, нежели чем производит "каверзных" зависимостей. 58155 4 viy 2007-11-13 22:50:37 +0300 > Прошу его использовать только в случае реальной необходимости, т.к. symlinks.req > отлавливает гораздо больше настоящих ошибок запаковки, нежели чем производит > "каверзных" зависимостей. Да, вещь хорошая. 58309 5 at 2007-11-17 09:42:23 +0300 Вы не написали, как нызвается пакет, в котором symlinks.req даёт слишком конкретную зависимость. У меня сейчас есть немного времени, чтобы это дело поковырять, но я уже трачу его на поиски подходящего пакета, чтобы обдумать что к чему. 58311 6 viy 2007-11-17 11:11:19 +0300 например maven-1.1. В нем сейчас стоит AutoReq: yes,nosymlinks если убрать должно воспроизвестись если не ошибаюсь с /usr/lib/jvm/java//jre/lib/tools.jar 58312 7 at 2007-11-17 12:10:51 +0300 Проблема очень плохая. Есть примеры из базовой системы гораздо проще -- напр. /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! 58314 8 viy 2007-11-17 12:40:22 +0300 гм. в случае с /usr/share/libtool/../../bin/perl /usr/bin/perl (разрешение симлинка) и /usr/share/libtool (альтернатива) принадлежат разным пакетам. В этом случае имеет смысл выдать предупреждение, а зависимость ставить на /usr/bin/perl (как было раньше) либо вообще не ставить. если же (разрешение симлинка) и (альтернатива) предоставляются одим и тем же пакетом, то зависимость нужно ставить не на этот пакет, а на альтернативу, которую он предоставляет. 58315 9 at 2007-11-17 13:19:15 +0300 Хочу на всякий случай заметить, что проблема не специфична для symlinks.req. Речь идёт об общих принципах разрешения путей в зависимости. 58317 10 at 2007-11-17 15:06:31 +0300 Кажется, несмотря на кипение головы, все проблемы с альтернативами таки удалось решить. Прошу посмотреть 4.0.4-alt80-2-g2bf12ba (а также предыдущий коммит). 58318 11 viy 2007-11-17 15:39:51 +0300 хорошо. 67043 12 at 2008-03-31 04:47:49 +0400 This was fixed in 4.0.4-alt81.