Bug 13374 - symlinks.req should test alternatives in path
: symlinks.req should test alternatives in path
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2007-11-09 19:44 by
Modified: 2008-04-23 11:47 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-11-09 19:44:18
если симлинк указывает на файл в "за-альтернатированной" директории
например, 
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.
.
------- Comment #1 From 2007-11-10 00:38:33 -------
То есть при разрешении симлинка выясняется, что один из промежуточных
катаологов
в свою очередь опять является симлинком, который висит на альтернативах.

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

В любом случае, то что Вы предлагаете, если я правильно понимаю, в этом случае
какая бы то ни была зависимоть на rt.jar потеряется.  Зависимость на
/usr/lib/jvm/java не гарантирует, что где-то под этим каталогом будет лажать
rt.jar.

Конкретная зависимость лучше никакой, потому что она гарантерует что файл
rt.jar
будет на месте.  Надо подумать...
------- Comment #2 From 2007-11-13 17:26:22 -------
> Конкретная зависимость лучше никакой, потому что она гарантерует что файл 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.
------- Comment #3 From 2007-11-13 21:12:41 -------
Хорошо.  Я понимаю, что "правильную" (необходимой и достаточную) зависимость
здесь указать очень сложно.  Я попробую реализовать в symlinks.req проверку на
прохождение пути через альтернативы.

Текущий workaround --
%add_findreq_skiplit /path/to/symlink

Прошу его использовать только в случае реальной необходимости, т.к.
symlinks.req
отлавливает гораздо больше настоящих ошибок запаковки, нежели чем производит
"каверзных" зависимостей.
------- Comment #4 From 2007-11-13 22:50:37 -------
> Прошу его использовать только в случае реальной необходимости, т.к. symlinks.req
> отлавливает гораздо больше настоящих ошибок запаковки, нежели чем производит
> "каверзных" зависимостей.
Да, вещь хорошая.
------- Comment #5 From 2007-11-17 09:42:23 -------
Вы не написали, как нызвается пакет, в котором symlinks.req даёт слишком
конкретную зависимость.  У меня сейчас есть немного времени, чтобы это дело
поковырять, но я уже трачу его на поиски подходящего пакета, чтобы обдумать что
к чему.
------- Comment #6 From 2007-11-17 11:11:19 -------
например maven-1.1. В нем  сейчас стоит
AutoReq: yes,nosymlinks
если убрать должно воспроизвестись
если не ошибаюсь с /usr/lib/jvm/java//jre/lib/tools.jar
------- Comment #7 From 2007-11-17 12:10:51 -------
Проблема очень плохая.  Есть примеры из базовой системы гораздо проще --
напр. /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!
------- Comment #8 From 2007-11-17 12:40:22 -------
гм. в случае с /usr/share/libtool/../../bin/perl 
/usr/bin/perl (разрешение симлинка) и /usr/share/libtool (альтернатива)
принадлежат разным пакетам. В этом случае 
имеет смысл выдать предупреждение, а зависимость ставить на /usr/bin/perl (как
было раньше) либо вообще не ставить.
если же (разрешение симлинка) и (альтернатива) предоставляются одим и тем же 
пакетом, то зависимость нужно ставить не на этот пакет, а на альтернативу,
которую он предоставляет.
------- Comment #9 From 2007-11-17 13:19:15 -------
Хочу на всякий случай заметить, что проблема не специфична для symlinks.req.
Речь идёт об общих принципах разрешения путей в зависимости.
------- Comment #10 From 2007-11-17 15:06:31 -------
Кажется, несмотря на кипение головы, все проблемы с альтернативами таки удалось
решить.  Прошу посмотреть 4.0.4-alt80-2-g2bf12ba (а также предыдущий коммит).
------- Comment #11 From 2007-11-17 15:39:51 -------
хорошо.
------- Comment #12 From 2008-03-31 04:47:49 -------
This was fixed in 4.0.4-alt81.