Bug 13374 - symlinks.req should test alternatives in path
Summary: symlinks.req should test alternatives in path
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm-build (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-09 19:44 MSK by viy
Modified: 2008-04-23 11:47 MSD (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description viy 2007-11-09 19:44:18 MSK
если симлинк указывает на файл в "за-альтернатированной" директории
например, 
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 at@altlinux.org 2007-11-10 00:38:33 MSK
То есть при разрешении симлинка выясняется, что один из промежуточных катаологов
в свою очередь опять является симлинком, который висит на альтернативах.

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

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

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

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

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