Сразу пример: # rpm -qR fglrx_glx xorg-x11-server >= 1.1.99.903-alt3 xorg-x11-extensions-glx >= 1.1.0 # rpm -qR i586-fglrx_glx fglrx_glx = 8.50.1-alt1.biarch1 А i586-fglrx_glx хорошо бы чтобы ещё зависел от i586-xorg-x11-extensions-glx. А переименованый i586-xorg-extensions-glx ещё бы и предоставлял provides на i586-xorg-x11-extensions-glx. Начал писать алгоритм автомата, но сразу понял что дело гиблое. Нам хотя бы руками Requires/Provides выставлть было бы неплохо...
Если пакеты 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 и пушну.
http://git.altlinux.org/people/mike/packages/?p=arepo.git
2 rider: вот этот патч тогда показывал.
Патч втянул, хак after-tags добавил.
Спасибо!
Сегодня впервые воспользовался x86_32. Результат удивил: при установке пакетов i586-* по зависимостям не вытянулось даже i586-glibc-core!!! Предлагаю переоткрыть баг.
Стоит ещё проверить патч из bug #25192; возможно, на production сейчас ещё более старый arepo.
