Bug 7017 - multilib fix
: multilib fix
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/xml-commons-which)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-06-06 18:25 by
Modified: 2005-06-29 17:16 (History)


Attachments
mutlilib fixes (899 bytes, application/octet-stream)
2005-06-06 18:26, Kachalov Anton
no flags Details


Note

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


Description From 2005-06-06 18:25:40
multilib fix
------- Comment #1 From 2005-06-06 18:26:29 -------
Created an attachment (id=922) [details]
mutlilib fixes
------- Comment #2 From 2005-06-06 18:30:30 -------
ещё нужно зафиксить, чтобы xml-commons-which не хотел
%_libdir/java-common/java-functions. Это общая проблема - пакет последний раз
собирался очень давно.
------- Comment #3 From 2005-06-09 00:30:25 -------
java-common, в который входит java-functions, у нас noarch.
xml-commons-which тоже. Каким боком здесь появляется x86_64?

Может быть, имеет смысл менять %_libdir при сборке только для пакетов,
совместимых с x86_64?
------- Comment #4 From 2005-06-09 10:31:52 -------
Тогда нужно фиксить пакет java-common, чтобы он клал java-functions в
/usr/share/... Если java-functions нельзя класть в /usr/share из-за
arch-depends, то тогда делать xml-commons-which архитектурно-зависимым. Но
xml-commons-which придётся фиксить в любом случае. Даже потому, что на i586
появляется unmet при пересборке для этого пакета (сам пакет последний раз
собирался в 2002 году).
------- Comment #5 From 2005-06-17 11:08:41 -------
В чем проблема использования %_libdir в noarch-пакетах?
Почему при пересборке xml-commons-which появляется unmet?
------- Comment #6 From 2005-06-17 14:36:36 -------
Предлагаю просто взять текующий src.rpm и пересобрать в hasher'e.
Просто с 2002'го года очень многое изменилось, в том числе и анализ
shell-скриптов на предмет зависимостей. Раньше этого не было.
$ sh --rpm-requires /usr/bin/xml-which
executable(/usr/lib64/java-common/java-functions)
executable(AddToClasspath)
executable(java)
------- Comment #7 From 2005-06-17 14:42:17 -------
проблема в том, что если я соберу noarch-пакет на x86_64, где %_libdir ==
/usr/lib64, то поставив этот пакет в систему, где %_libdir == /usr/lib, получу
неработающую компоненту. вроде, всё очевидно :)
------- Comment #8 From 2005-06-18 11:32:14 -------
(In reply to comment #7)
> проблема в том, что если я соберу noarch-пакет на x86_64, где %_libdir ==
> /usr/lib64, то поставив этот пакет в систему, где %_libdir == /usr/lib, получу
> неработающую компоненту. вроде, всё очевидно :)

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

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

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

Зачем лечить следствие, когда нужно устранить причину?
------- Comment #11 From 2005-06-18 16:12:41 -------
А почему %_lib для x86_64 должно иметь другое значение?! Какая разница - arch
или noarch?!
------- Comment #12 From 2005-06-18 16:21:41 -------
Я ничего не знаю про пакет xml-commons-which, но одно я знаю точно:
Пакет может быть noarch если только его можно собрать на любой архитектуре и
при
этом получится одинаковый результат.
Как следствие, если в пакете фигурирует %_libdir, то он не может быть noarch.
------- Comment #13 From 2005-06-25 18:17:24 -------
Fixed in 1.0-alt0.2.b2.
------- Comment #14 From 2005-06-29 17:16:12 -------
thanks