7017 2005-06-06 18:25:40 +0400 multilib fix 2005-06-29 17:16:12 +0400 1 1 4 Development Sisyphus xml-commons-which unstable all Linux CLOSED FIXED P2 normal --- 1 mouse mhz ldv qa-sisyphus oldest_to_newest 25327 0 mouse 2005-06-06 18:25:40 +0400 multilib fix 25328 1 922 mouse 2005-06-06 18:26:29 +0400 Created attachment 922 mutlilib fixes 25329 2 mouse 2005-06-06 18:30:30 +0400 ещё нужно зафиксить, чтобы xml-commons-which не хотел %_libdir/java-common/java-functions. Это общая проблема - пакет последний раз собирался очень давно. 25448 3 mhz 2005-06-09 00:30:25 +0400 java-common, в который входит java-functions, у нас noarch. xml-commons-which тоже. Каким боком здесь появляется x86_64? Может быть, имеет смысл менять %_libdir при сборке только для пакетов, совместимых с x86_64? 25468 4 mouse 2005-06-09 10:31:52 +0400 Тогда нужно фиксить пакет java-common, чтобы он клал java-functions в /usr/share/... Если java-functions нельзя класть в /usr/share из-за arch-depends, то тогда делать xml-commons-which архитектурно-зависимым. Но xml-commons-which придётся фиксить в любом случае. Даже потому, что на i586 появляется unmet при пересборке для этого пакета (сам пакет последний раз собирался в 2002 году). 25942 5 mhz 2005-06-17 11:08:41 +0400 В чем проблема использования %_libdir в noarch-пакетах? Почему при пересборке xml-commons-which появляется unmet? 25953 6 mouse 2005-06-17 14:36:36 +0400 Предлагаю просто взять текующий src.rpm и пересобрать в hasher'e. Просто с 2002'го года очень многое изменилось, в том числе и анализ shell-скриптов на предмет зависимостей. Раньше этого не было. $ sh --rpm-requires /usr/bin/xml-which executable(/usr/lib64/java-common/java-functions) executable(AddToClasspath) executable(java) 25954 7 mouse 2005-06-17 14:42:17 +0400 проблема в том, что если я соберу noarch-пакет на x86_64, где %_libdir == /usr/lib64, то поставив этот пакет в систему, где %_libdir == /usr/lib, получу неработающую компоненту. вроде, всё очевидно :) 25998 8 mhz 2005-06-18 11:32:14 +0400 (In reply to comment #7) > проблема в том, что если я соберу noarch-пакет на x86_64, где %_libdir == > /usr/lib64, то поставив этот пакет в систему, где %_libdir == /usr/lib, получу > неработающую компоненту. вроде, всё очевидно :) Давайте зрить в корень проблемы: почему %_libdir вообще определяется как /usr/lib64 для архитектуры noarch? 26000 9 mouse 2005-06-18 13:50:33 +0400 (In reply to comment #8) > Давайте зрить в корень проблемы: почему %_libdir вообще определяется как > /usr/lib64 для архитектуры noarch? Потому, что %_libdir = %_prefix/%_lib, а %_lib не обязательно равен lib. Для архитектур x86_64, ppc64, sparc64 это lib64. Поэтому я и предлагаю сделать его arch-пакетом. Для справки: у нас уже на след. неделе в Сизифе появятся x86_64-пакеты. 26001 10 mhz 2005-06-18 14:34:03 +0400 (In reply to comment #9) > Потому, что %_libdir = %_prefix/%_lib, а %_lib не обязательно равен lib. Для > архитектур x86_64, ppc64, sparc64 это lib64. В пакете проставлена архитектура noarch. Почему при его сборке %_lib определяется в lib64? > Поэтому я и предлагаю сделать его > arch-пакетом. Зачем лечить следствие, когда нужно устранить причину? 26007 11 mouse 2005-06-18 16:12:41 +0400 А почему %_lib для x86_64 должно иметь другое значение?! Какая разница - arch или noarch?! 26008 12 ldv 2005-06-18 16:21:41 +0400 Я ничего не знаю про пакет xml-commons-which, но одно я знаю точно: Пакет может быть noarch если только его можно собрать на любой архитектуре и при этом получится одинаковый результат. Как следствие, если в пакете фигурирует %_libdir, то он не может быть noarch. 26420 13 mhz 2005-06-25 18:17:24 +0400 Fixed in 1.0-alt0.2.b2. 26625 14 mouse 2005-06-29 17:16:12 +0400 thanks 922 2005-06-06 18:26:29 +0400 2005-06-06 18:26:29 +0400 mutlilib fixes xml-commons-x86_64.tar.bz2 application/octet-stream 899 mouse QlpoOTFBWSZTWRwLkfAAAvh/hO24AIB/n//9fr/f3v//3/AAAQAIQAMdUtQqyMQ1T1MUZHqYjRG9 CTbSmj1G1NAGmQ0ADQAPUbUaDJNGppk1TaaT0iPKafqgaaeiMjQ0MhoANAGnqGmhzTEZGTTJoBkN GQyZAAADI0yNAwhkCSRDRGmiegU80AU9CeUepoAAABoeoGgep6nA9y9/PViM8aogCTSoSRFny23i exobQ7TblFBDIAAkhkvDL6Q+XzZf2p/hojzZXac98IoMgEiqc71et6skdmFtqmuhGk5DKlMhwfmf qvC/O7B2ahzylfrBu2T2iqfuYg3hctE195hJYfaxKGq48WgyjxXwognZBqkGC8vicBQumnRrhNZz AgVD0pe5ORMzWOX9mGeMM8DUQ5tIIYGEJv7h2iQoGIEw9DUa9WkcYdECWeJqdeqaBM0/YMeM1IGI 1xvsI2euRFYEZ7eWA7FPZu6Ho6h2tcW7OTFmGgUSqEIhVFwHTRBMDl3pHK8gYV057gnDDxbc0ieR LMOQOWawz+ok+ObVF6YgpQMAJHAvgJCatwvfW8LCwVeneZouWrzomTftYqiLJEmmpQbJqD/MoE5Q BqKBxlIM8ugBHbDzpKV6oat+sZLEVsjBzlv6pUKz16W9wYCSQz0pptHN2ndcHD7lT3DkcKc+4sE+ Z6I41HIeTiC6KOU8o754HhplKmiyQ/fQRKc6BiZPtF427YjilPRbIjlZGRWy0bgpcd/yAog/nLtT 9sOLcEXQF4zjwsP0zZKr+aRbhp2R5bW0xAebdYPO7AcmHxkXNcs7BkxTGFas0cl1Ia+nlsvSa67r SugNpCK74YtlVpkZVhAMTgVjIRqomG8vbrJtZl0qHbYuy1XpPOQHiWxICPHhiC7guiyQ/iBiNnuE DKgr6LEID63Ni9BLRUXuacpI0Vwj0wOnNxR4gZsWGq1dsvcIfvfTyjjkr0kIxmYJGWWOZ6p3y0iJ aAUAWdb1CtHPByKGMNJEoqISIT3w1vTse7CGW/YvvSJbmS4njMDAQs1CZh1q57ESY5sd+qwCX2Oc gDOGoYJsVNAxz/5wtgHZMZEtKOAFJg4oh1eAuGPG8wbHJThYKkfclgFogBdhOjPvD0UZq1trhisy 6N3oF5Av5zYbnuxEBcNc62WDgpgXaxw4feKJmjul/jQB/xdyRThQkBwLkfA=