(In reply to comment #0)
> # apt-get install mvapich-gcc
> Reading Package Lists... Done
> Building Dependency Tree... Done
> The following extra packages will be installed:
>   mpi-selector mvapich-gcc-devel
> The following packages will be upgraded
>   mpi-selector mvapich-gcc mvapich-gcc-devel
> The following packages will be REMOVED:
>   i586-mvapich-gcc-devel.32bit i586-mvapich-gcc.32bit
> 
> # rpm -q i586-mvapich-gcc
> i586-mvapich-gcc-1.0.1-alt3.M41.1
> 
> Итого, apt понимает, что надо снести i586-й клон, но не делает это.

Кто виноват, libapt или librpm?

> Делаю высокий приоритет баге ибо это постоянно ломает целостность системы
> на машинах, которые вынуждены использовать этот "биарч".

Не все дистрибутивы используют биарч -> не блокер.

Помимо прочего, хотелось бы заметить, что перепаковка при помощи arepo/mkbaselibs/whatever небиблиотечных пакетов -- очень и очень плохая идея, которая doomed to fail тем или иным образом всё равно.

(In reply to comment #2)
> Помимо прочего, хотелось бы заметить, что перепаковка при помощи
> arepo/mkbaselibs/whatever небиблиотечных пакетов -- очень и очень плохая идея, которая
> doomed to fail тем или иным образом всё равно.
Пока не будет biarch у меня нет иного выбора ибо мне нужно иметь две исполняемые среды MPI на машине одновременно.

(In reply to comment #1)
> (In reply to comment #0)
> > # apt-get install mvapich-gcc
> > Reading Package Lists... Done
> > Building Dependency Tree... Done
> > The following extra packages will be installed:
> >   mpi-selector mvapich-gcc-devel
> > The following packages will be upgraded
> >   mpi-selector mvapich-gcc mvapich-gcc-devel
> > The following packages will be REMOVED:
> >   i586-mvapich-gcc-devel.32bit i586-mvapich-gcc.32bit
> > 
> > # rpm -q i586-mvapich-gcc
> > i586-mvapich-gcc-1.0.1-alt3.M41.1
> > 
> > Итого, apt понимает, что надо снести i586-й клон, но не делает это.
> 
> Кто виноват, libapt или librpm?
Без понятия. Поэтому и добавил в CC at@. Воспроизводится отлично, так что можно вставить отладку и в ту и в другую библиотеку ;)

(In reply to comment #3)
> Пока не будет biarch у меня нет иного выбора ибо мне нужно иметь две
> исполняемые среды MPI на машине одновременно.

Давайте определимся, что мы понимаем под словом "biarch".
Обычно слово "biarch" *не* означает возможности установки произвольных исполняемых пакетов двух архитектур друг на друга.
Обычно слово "biarch" означает исключительно возможность создания *сборочной* среды другой архитектуры из пары на данной, каковую затем может использовать *один* gcc с поддержкой multilib для сборки бинарей разных архитектур.

(In reply to comment #5)
> (In reply to comment #3)
> > Пока не будет biarch у меня нет иного выбора ибо мне нужно иметь две
> > исполняемые среды MPI на машине одновременно.
> 
> Давайте определимся, что мы понимаем под словом "biarch".
> Обычно слово "biarch" *не* означает возможности установки произвольных
> исполняемых пакетов двух архитектур друг на друга.
> Обычно слово "biarch" означает исключительно возможность создания *сборочной*
> среды другой архитектуры из пары на данной, каковую затем может
> использовать *один* gcc с поддержкой multilib для сборки бинарей разных
> архитектур.
Я совершенно не против идеальной трактовки, но жизнь думает иначе ;)

А именно, если rpm-ы могут вставать одновременно безотносительно к своему содержимому, то люди начинают желать этим пользоваться.

Кроме того есть пакеты типа grub, которые есть только i586 и надо уметь их ставить. А из-за того что arepo убивает скрипты то ...

(In reply to comment #6)

> А именно, если rpm-ы могут вставать одновременно безотносительно к своему
> содержимому, то люди начинают желать этим пользоваться.

Ну это проблемы этих людей, не так ли? ;) Использование фичи одновременной установки rpm'ок разных архитектур требует очень большой аккуратности и ума. Делать это бездумно нельзя -- собственно, пример с mpi-gcc это демонстрирует.

Скажем даже так: в данный момент имеющееся у меня представление о будущем альтовом биарче ровно такое, как я описал выше, и я буду делать именно так :) собственно, за референс реализацией можно посмотреть в SuSE.

> Кроме того есть пакеты типа grub, которые есть только i586 и надо уметь их
> ставить. А из-за того что arepo убивает скрипты то ...

http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86_64/grub-0.97-126.1.x86_64.rpm

?

P.S. BTW, все эти обсуждения не отменяют явно имеющегося косяка в librpm :)

(In reply to comment #7)
> (In reply to comment #6)
> 
> > А именно, если rpm-ы могут вставать одновременно безотносительно к своему
> > содержимому, то люди начинают желать этим пользоваться.
> 
> Ну это проблемы этих людей, не так ли? ;) Использование фичи одновременной
> установки rpm'ок разных архитектур требует очень большой аккуратности и ума.
> Делать это бездумно нельзя -- собственно, пример с mpi-gcc это демонстрирует.
mpvapich-gcc как раз ничего не демонстрирует. Там всё очень аккуратно разнесено. Придумай как сделать это же решение иначе.
Учти, что тут мы делали всё "на заказ" и добробольно я бы сам такое никогда не стал бы делать ;)
> 
> Скажем даже так: в данный момент имеющееся у меня представление о будущем
> альтовом биарче ровно такое, как я описал выше, и я буду делать именно так :)
> собственно, за референс реализацией можно посмотреть в SuSE.
Не против ;)
> 
> > Кроме того есть пакеты типа grub, которые есть только i586 и надо уметь их
> > ставить. А из-за того что arepo убивает скрипты то ...
> 
> http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86_64/grub-0.97-126.1.x86_64.rpm
Это нужно сообщить raorn@ ;)

(In reply to comment #8)
> > http://download.opensuse.org/distribution/openSUSE-current/repo/oss/suse/x86_64/grub-0.97-126.1.x86_64.rpm
> Это нужно сообщить raorn@ ;)

Там внутри grub.i586, а i586-* в наши BuildRequires непролазят.

fixed in 0.5.15lorg2-alt25