[devel] glibc-devel-static biarch

[Anton Farygin]

Aleksey Novodvorsky пишет:
> 31 марта 2009 г. 22:01 пользователь Serge Ryabchun
> <serge.ryabchun на gmail.com> написал:
>> 2009/3/31 Wartan Hachaturow <wartan.hachaturow на gmail.com>:
>>>> Вартан, извини пожалуйста за публичность, но в _твои_ руки _завтра_ я уже не
>>>> верю.
>>> (пожимая плечами)
>>> Твоё право. Верь в Леда :)) Главное -- во что-нибудь верить.
>> Вартан, меня ты тоже извини за публичность, но не нужно ставить
>> удвоенную ухмылку в отношении led на . В данный момент он сильно ближе к
>> решению, чем ты. Даже, если решение в итоге окажется локальным и не
>> будет принято в Альте.
> 
> Очевидно, будет принято лучшее из доступных решений.
> Лично мне доводы  at@ кажутся важными, а количество решаемых при
> помощи rpm coloring неспециальных задач, -- незначительным и
> стремительно уменьшающимся. Практически все Вы здесь перечислили. На
> мой взгляд, существенной проблемой в перспективе полугода-года явлется
> лишь wine, который на достаточно мощной 64-битной станции (а есть ли
> другие, дающие  выигрыш в производительности несерверных приложений?),
> можно запустить в виртуальной машине как подсистему для унаследованных
> Win32-приложений.

Алексей, всё намного прозрачнее. Нужна возможность выкладывать в x86_64 
Sisyphus пакеты, слинкованные с 32-bit библиотеками. Или в ppc32 
Sisyphus пакеты, слинкованные с ppc64 библиотеками...

Например, для поддержки виндёвых плагинов у видео-проигрывателей или 
поддержки 32-bit плагинов у mozilla, или для сборки grub и wine (именно 
сборки, а не установки wine.32bit).

Многое для чего.. это разрешило бы массу проблем. Как это будет 
реализовано - дело десятое и лично меня это волнует в последнюю очередь. 
Главное - что бы работало и работало хорошо.

Про два пути решения этой проблемы всем уже известно...