Bug 13374

То есть при разрешении симлинка выясняется, что один из промежуточных катаологов
в свою очередь опять является симлинком, который висит на альтернативах.

Очень шаткая конструкция.

В любом случае, то что Вы предлагаете, если я правильно понимаю, в этом случае
какая бы то ни была зависимоть на 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.