Bug 7017

Created attachment 922 [details]
mutlilib fixes

ещё нужно зафиксить, чтобы xml-commons-which не хотел
%_libdir/java-common/java-functions. Это общая проблема - пакет последний раз
собирался очень давно.

java-common, в который входит java-functions, у нас noarch.
xml-commons-which тоже. Каким боком здесь появляется x86_64?

Может быть, имеет смысл менять %_libdir при сборке только для пакетов,
совместимых с x86_64?

Тогда нужно фиксить пакет java-common, чтобы он клал java-functions в
/usr/share/... Если java-functions нельзя класть в /usr/share из-за
arch-depends, то тогда делать xml-commons-which архитектурно-зависимым. Но
xml-commons-which придётся фиксить в любом случае. Даже потому, что на i586
появляется unmet при пересборке для этого пакета (сам пакет последний раз
собирался в 2002 году).

В чем проблема использования %_libdir в noarch-пакетах?
Почему при пересборке xml-commons-which появляется unmet?

Предлагаю просто взять текующий src.rpm и пересобрать в hasher'e.
Просто с 2002'го года очень многое изменилось, в том числе и анализ
shell-скриптов на предмет зависимостей. Раньше этого не было.
$ sh --rpm-requires /usr/bin/xml-which
executable(/usr/lib64/java-common/java-functions)
executable(AddToClasspath)
executable(java)

проблема в том, что если я соберу noarch-пакет на x86_64, где %_libdir ==
/usr/lib64, то поставив этот пакет в систему, где %_libdir == /usr/lib, получу
неработающую компоненту. вроде, всё очевидно :)

(In reply to comment #7)
> проблема в том, что если я соберу noarch-пакет на x86_64, где %_libdir ==
> /usr/lib64, то поставив этот пакет в систему, где %_libdir == /usr/lib, получу
> неработающую компоненту. вроде, всё очевидно :)

Давайте зрить в корень проблемы: почему %_libdir вообще определяется как
/usr/lib64 для архитектуры noarch?

(In reply to comment #8)
> Давайте зрить в корень проблемы: почему %_libdir вообще определяется как
> /usr/lib64 для архитектуры noarch?
Потому, что %_libdir = %_prefix/%_lib, а %_lib не обязательно равен lib. Для
архитектур x86_64, ppc64, sparc64 это lib64. Поэтому я и предлагаю сделать его
arch-пакетом.
Для справки: у нас уже на след. неделе в Сизифе появятся x86_64-пакеты.

(In reply to comment #9)
> Потому, что %_libdir = %_prefix/%_lib, а %_lib не обязательно равен lib. Для
> архитектур x86_64, ppc64, sparc64 это lib64.

В пакете проставлена архитектура noarch.
Почему при его сборке %_lib определяется в lib64?

> Поэтому я и предлагаю сделать его
> arch-пакетом.

Зачем лечить следствие, когда нужно устранить причину?

А почему %_lib для x86_64 должно иметь другое значение?! Какая разница - arch
или noarch?!

Я ничего не знаю про пакет xml-commons-which, но одно я знаю точно:
Пакет может быть noarch если только его можно собрать на любой архитектуре и при
этом получится одинаковый результат.
Как следствие, если в пакете фигурирует %_libdir, то он не может быть noarch.

Fixed in 1.0-alt0.2.b2.

thanks