Summary: | Трансляция зависимостей у i586-* | ||||||
---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | Sir Raorn <raorn> | ||||
Component: | arepo | Assignee: | Nobody's working on this, feel free to take it <nobody> | ||||
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
Severity: | enhancement | ||||||
Priority: | P2 | CC: | damir, ildar, kopilo4ka, ldv, mike, rider, sr | ||||
Version: | unstable | ||||||
Hardware: | all | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Sir Raorn
2008-07-04 16:26:49 MSD
Если пакеты A и B присутствуют в конфиге, и A зависит от B, то i586-A должен в результате зависеть от i586-B. Про это был коммит daf96e, он вроде даже работал. Руками дописывать — ну добавлю, пожалуй, хак after-tags. Created attachment 4066 [details]
arepo.py patch to resolve package names thus saving apt from insanity
Disclaimer: я (пока?) не являюсь пользователем arepo и могу опираться только на слова других людей, в т.ч. читанное в рассылках.
--- со слов sr@ ---
У arepo к проблеме рассинхронизации добавляется проблема
"невозможности провести апгрейд".
---
<sr>
[sr@sr RPMS.classic]$ rpm -R -p i586-libX11-1.2-alt1.i586.rpm
libX11 = 3:1.2-alt1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.2)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3.2)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libxcb.so.1
rtld(GNU_HASH)
rpmlib(PayloadIsLzma) <= 4.4.2-1
[sr@sr RPMS.classic]$ rpm -R -p i586-libxcb-1.2-alt2.i586.rpm
libxcb = 1.2-alt2
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
libXau.so.6
libXdmcp.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.3.2)
libc.so.6(GLIBC_2.3.4)
libc.so.6(GLIBC_2.4)
rtld(GNU_HASH)
rpmlib(PayloadIsLzma) <= 4.4.2-1
[sr@sr RPMS.classic]$ rpm -R -p i586-libX11-1.2-alt1.i586.rpm
libX11 = 3:1.2-alt1
i586-glibc-core
i586-libxcb
[sr@sr RPMS.classic]$ rpm -R -p i586-libxcb-1.2-alt2.i586.rpm
libxcb = 1.2-alt2
i586-libXau
i586-libXdmcp
i586-glibc-core
Правильно я понимаю, что так была бы рабочая конфигурация для `apt-get update`?
<eostapets> Ну не то, чтобы рабочая, но при обновлении не клинило бы...
<sr> А что нерабочего было бы?
<eostapets> То, что собрать пакеты с такими зависимостями без ошибок очень и очень сложно...
<sr> Разумное допущение, если libnameX.so.1 требует libnameY.so.2, которая провайдится пакетом libnameY, то подразумевается, что этот пакет для multilib будет называться i586-libnameY. И все. Проблема, если перед этим был пакет libnameY1 и i586-libnameY1, и текущий libnameY замещает libnameY1
<eostapets> В момент паковки libnameX.so.1 мы не знаем, в каком пакете находится 64-bit libnameY.so.2 и соотвественно какое будет имя 32-bit пакета.
<sr> мы пакуем 32bit-пакет, в этот момент в хешере установлен пакет с libnameY.so.2, т.е. ldd libnameX.so.1 дает список list,
rpmlist=`for i in $list; do rpm -qf $i; done|sort|uniq`
reqlist=`for i in rpmlist; do echo i586-$i; done`
---
Патч втащил к себе в arepo.git, сейчас поправлю насчёт /tmp и пушну. 2 rider: вот этот патч тогда показывал. Патч втянул, хак after-tags добавил. Спасибо! Сегодня впервые воспользовался x86_32. Результат удивил: при установке пакетов i586-* по зависимостям не вытянулось даже i586-glibc-core!!! Предлагаю переоткрыть баг. Стоит ещё проверить патч из bug #25192; возможно, на production сейчас ещё более старый arepo. |