В тестинге наконец-то появился dpkg с поддержкой multiarch

Тут главное-то что? В Debian всё работает, а в Ubuntu, как всегда, убунтопроблемы, вот.

В дебиане - гладко :)

В дебиане - гладко :)

даже идеально, wine - доисторическая версия даже в experimental, skype - вообще нет, сторонние пакеты используют ia32-libs, т.е. использовать multiarch по сути вообще нет смысла

wine - доисторическая версия даже в experimental, skype - вообще нет, сторонние пакеты используют ia32-libs

ничесе, это в дебиане так уныло?

это в дебиане так уныло?

вроде бы связано с лицензионной политикой, но точно не скажу причины

вроде бы связано с лицензионной политикой

вот по этой причине я не на дебиане, слишком он чист, иногда боком выходит

вроде бы связано с лицензионной политикой

Тогда бы вынесли в non-free.

В дебиане - гладко :)

т.е. там ключик --add-architecture или --foreign-architecture все таки отрабатывает?

Тогда бы вынесли в non-free.

почему тогда туда лого firefox не выносят? видимо не все может быть в репах дебиана

ia32-libs - старое протухшее говно мамонта. Пример: там меза 7.7, а для моего сандибриджа нужно хотя бы 7.10. И это первое мое применение multiarch: благодаря ему у меня теперь есть нормальная 32-битная меза => возможность запускать 3D-приложения в wine.

wine есть в wine-unstable и убунтовых репах (последний на дебиан работает более, чем нормально).

А multiarch полезен еще и для кросскомпиляции и для безболезненного перехода с одной архитектуры на другую без сноса системы (раньше, чтобы сделать это с дебианом, нужны были серьезные извращения, теперь же все просто).

почему тогда туда лого firefox не выносят?

facepalm.svgz

видимо не все может быть в репах дебиана

wine там есть, везде, кроме testing.

Пакет со скайпом ты можешь получить на skype.com, пакет с wine - на wine-unstable или из убунтовского ppa.

skype в официальных репах нет из-за лицензии, wine старый из-за слоупоков-мейнтейнеров (в списке рассылки обсуждалось, что мол там какой-то затык с опакечиванием новых версий).

Где именно он чист и где это боком выходит?

ia32-libs - старое протухшее говно мамонта.

никто и не спорит

wine есть в wine-unstable и убунтовых репах (последний на дебиан работает более, чем нормально).

и с этим я согласен

А multiarch полезен еще и для кросскомпиляции

знаю - использую

и для безболезненного перехода с одной архитектуры на другую

а вот это нереально по очевидным причинам

--add-architecture i386

Из мана:

--add-architecture architecture
              Add architecture to the list of architectures for which packages can be installed without using --force-architecture. The architecture dpkg is built for (i.e. the output  of
              --print-architecture) is always part of that list.

Лого файрфокса не нужно просто никому, вот и всё.

Лого файрфокса не нужно просто никому, вот и всё.

они не имеют права его использовать, вносишь изменения в firefox - будь добр обозвать полученный продукт по другому

--add-architecture i386

вопрос в другом: в дебиане то хоть один из этих ключей пашет? вы же говорите гладко

а вот это нереально по очевидным причинам

Например?

Раньше был вот такой вот способ: http://users.digitalkingdom.org/~rlpowell/hobbies/debian_arch_up/

Сейчас можно сделать то же самое по-человечески, безопасно, без извращений.

А не лучше ли подождать, пока х86 таки подохнет?

Ну и <трололо>в винде и в ос х уже кучу времени всё просто и прозрачно для юзера работает в плане возможности ставить и х86, и х86_64 программы</трололо>.

Пашет.

А не лучше ли подождать, пока х86 таки подохнет?

wine требует.

Ну и multiarch не только для x86 полезен.

<трололо>в винде и в ос х уже кучу времени всё просто и прозрачно для юзера работает в плане возможности ставить и х86, и х86_64 программы</трололо>

<трололо> а в винде и маке можно то же самое делать для итаников, армов, спарков, паверов, чппа, мипсов, моторол68к, авр32, s390, sh4, альф? </трололо>

wine требует.

Wine требует полторы сторонних библиотеки, которые можно засунуть прям внутрь его пакета без особого оверхеда.

Ну и multiarch не только для x86 полезен.

Для бинарно несовместимых архитектур (а все остальные архитектуры дебиана да и линукса в общем являются таковыми) мультиарч особо и не нужен.

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

Например?

помимо библиотек, которые можно держать рядом, есть еще и программы, и их придется удалять и ставить заново, а, учитывая, что от всяких apt и пр. базовых пакетов много чего зависит - во-первых придется по сути руками переставить все пакеты, во-вторых есть риск оказаться в ситуации, когда какой-нибудь базовый пакет удалится при обновлении другого и дальнейшее обновление остановится либо в процессе установки, либо при выполнении постустановочных скриптов

Зачем мне пакет для арма, к примеру, на m68k?

http://xkcd.com/619/

Риск затыков с apt или dpkg есть, поэтому я бы перед этим в любом случае корень забэкапил.

Wine требует полторы сторонних библиотеки, которые можно засунуть прям внутрь его пакета без особого оверхеда.

Как обновлять по отдельности эти пакеты? А ALSA и mesa в любом случае придется обновлять, т.к. постоянно выходит новое железо, и на твоем следующем компьютере оно может не заработать. Раньше применялся ia32-libs, в который засовывали самые часто нужные либы. Но он намного сложнее в поддержке, ну и не все проги хотят одинаковых либ. В результате на данный момент в ia32-libs в Debian лежит говно мамонта, не поддерживающее мой sandy bridge.

а все остальные архитектуры дебиана да и линукса в общем являются таковыми

sparc64-ядро может работать со спарк32-бинарниками (даже дефолтный дебиановый порт на спарк (называется sparc) содержит 64-битное ядро и 32-битные бинарники, а полноценный sparc64 - неофициальный), ppc64-ядро может работать с ppc32-бинарниками. Продолжать?

Под померпц и спарки есть груз протухших и непересобираемых проприетарных программ или же иным образом прибитых к 32-бит варианту архитектуры?

Такая (как в случае с х86/х86_64) ситуация ещё имеет шанс случиться с arm, но маловероятно.