multilib fix
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
