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

Проведем мысленный эксперимент и предположим, что оно умеет ARM, Power, MIPS или чего там еще твоей душеньке угодно. Как твой x86-процессор будет это запускать?

во-первых их можно просто использовать для кросскомпиляции, во-вторых:

http://en.wikipedia.org/wiki/Rosetta_(software)

если запилят что-то похожее - для разработки под различные архитектуры будет самое оно

Могу я поставить, например, полный 32-битный Firefox на 64-битную систему из репозиториев при мультилибе?

Не понял, а что вам мешает?

В дебиане 100500 лет как в /usr/lib32 - 32битные либы, в /usr/lib - 64битные. Жили сносно, но ia32-libs - это костыль.

QEMU, например.

Как твой x86-процессор будет это запускать?

через qemu

а еще это надо будет когда до магазинов доедет loongson 3. Да и вообще не x86 совместимые процессоры

http://wiki.debian.org/Multiarch/TheCaseForMultiarch

Много букв. Прочитал бегло, так и не понял, в чём принципиальная разница. В двух словах можно?

С сегодняшнего дня - ничего. До сегодняшнего - то, каким жутко костыльным способом это было возможно сделать (по крайней мере, в дебиане).

в дебобунте на 32х битной системе в lib лежат 32х битные либы, поэтому всё равно пришлось бы разносить по разным директориям, а в Федоре сделали изначально правильно

Достаточно было прочесть это: http://wiki.debian.org/Multiarch/TheCaseForMultiarch#Benefit В частности, первый же пункт. В multiarch не выделяются «основная» архитектура и «эмулируемая», то есть без костылей можно держать произвольную солянку из архитектур.

На 64 бита можно ставить те же самые пакеты что и на 32. Это лучше ia32-libs тем, что доступны _все_ либы, собранные под 32бита, а также чем, что не надо собирать отдельный пакет.

С сегодняшнего дня - ничего. До сегодняшнего - то, каким жутко костыльным способом это было возможно сделать (по крайней мере, в дебиане).

И в чём заключался способ и его костыльность?

Первый повод для счастья: теперь у меня в 32-битных приложениях работает 3D на сандибриже, которое было до этого сломано (в ia32-libs очень древние либы, не поддерживающие еще сандибридж).

Два возможных способа:

1) искать 32-битный фокс, собранный для 64-битного дебиана. костыльность очевидна

2) зафорсить 32-битный фокс из 32-битного дебиана, попутно создав адЪ зависимостей и загадив /usr/lib 32-битными либами. костыльность очевидна

Да, получается, федора сразу сделала адекватно (хоть и не лучший способ, т.к. ограничивается только двумя архитектурами).

В multiarch не выделяются «основная» архитектура и «эмулируемая», то есть без костылей можно держать произвольную солянку из архитектур.

Звучит как погоня за архитектурной аккуратностью, не дающей конечному пользователю ощутимых преимуществ. Что такого я могу сделать с multiarch, чего никак не могу с multilib?

1) искать 32-битный фокс, собранный для 64-битного дебиана. костыльность очевидна

Кому очевидна? Мне - нет.

На 64 бита можно ставить те же самые пакеты что и на 32. Это лучше ia32-libs тем, что доступны _все_ либы, собранные под 32бита, а также чем, что не надо собирать отдельный пакет.

Да, мейнтейнерам удобно, согласен.

Например, вести разработку сразу под i386 и x86-64 без чрутов. В ia32-libs нет многих нужных либ.

В ia32-libs нет многих нужных либ.

«Не собрали» != «Нельзя собрать». Не думаю, что перепиливание половины дистрибутива и переделывание пакетного менеджера - менее ресурсозатратная процедура, чем сборка недостающих нужных либ. В конце концов, в хороших дистрибутивах пользователь может собрать себе нужный пакет сам за пять минут.

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

может, но в действительно хороших дистрибутивах - он не обязан этого делать

То что ты предлагаешь называется костыль.

о что ты предлагаешь называется костыль.

Про архитектурную аккуратность я уже понял. Про реальные преимущества - ещё нет.

Кто будет делать и поддерживать предлагаемый тобой костыль с запаковыванием нужных либ в ia32-wtf-lib ?

Дистрибутив перепиливается один раз, а делать двойную работу по поддержке говна придется делать постоянно.

Кто будет делать и поддерживать предлагаемый тобой костыль с запаковыванием нужных либ в ia32-wtf-lib ?

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

Но я не могу понять, чему все тут так радуются.

Удобству.

В каких во всех? Все rpm-based сто лет как работают по правильной схеме.

А как там?

32-битные библиотеки остались в /usr/lib, а 64-битные живут в /usr/lib64. Благодаря этому сохранилась совместимость со старыми 32-битными пакетами, которые можно было ставить на 64-битную систему без всяких лишних костылей. Естественным образом можно держать пакеты обеих битностей.

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

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

Актуальна. Выше я приводил ссылку.

Удобству.

Тут все поголовно майнтейнеры дебиана?

Все rpm-based сто лет как работают по правильной схеме.

Ну Ok. Во всех остальных, кроме RPM.

Тут все поголовно майнтейнеры дебиана?

Ась? Удобство пользователей. В хороших дистрибутивах не принято компилять, если можно обойтись без этого. И если тебе кажется, что собирать недостающее придётся лишь в редких случаях, ты ошибаешься.

И если тебе кажется, что собирать недостающее придётся лишь в редких случаях, ты ошибаешься.

Возможно. Примерчиком не поможете?

Актуальна.

Ну, кому-нибудь конечно актуальна. Просто за годы, прошедшие с момента появления х86-64 версий дистрибутивов, почти весь софт был портирован и надобность в 32-битных библиотеках сейчас гораздо меньше, чем тогда. Как вообще жили дебианщики — не понятно.

Примерчиком не поможете?

Включаем ы ALSA хороший ресэмплер, пытаемся запустить под wine любую игру — wine падает. Причина в отсутствии 32-битной версии пресловутого плагина в системе. И таких мелочей(?) полно.

Причина в отсутствии 32-битной версии пресловутого плагина в системе.

Нет в репах вообще? Тогда понятно.

Ты вообще хоть читаешь, на что отвечаешь? Такое чувство, что вместо тебя постит какой-то рекламный бот, который просто заходит в рандомную тему и пишет: «Ждём в агилии!» Даже я, человек, которому, в общем-то, положить на агилию, помню, что один из основных пунктов их философии — не deb, не rpm. Вот прав был Синус, когда говорил, что такие фанаты хуже врагов.

Ну и уверенное заявление о том, что там это точно будет, хотя сами разработчики ещё даже толком не знают, что там вообще будет, в очередной раз напоминают о твоём возрасте.

На 64-битной машине собирать софт под 32/64, а также, например, отлаживать (valgrind-ом). Правда, у нас убунта. И multiarch там глючит (в частности с valgrind-ом). Но тем не менее.

dpkg --foreign-architecture i386
dpkg: ошибка: укажите требуемое действие

man dpkg
--foreign-architecture architecture
              Add  architecture to the list of architectures for which packages can be installed without using --force-architecture, in addition to the architecture dpkg is built for (i.e.: the out‐
              put of --print-architecture).

dpkg --version 
Система управления пакетами Debian «dpkg», версия 1.16.1.2 (amd64).

Ubuntu 12.04

Чета кривой dpkg, приходится мультиарчность руками прописывать

dpkg --add-architecture i386

В твоей убунте ман кривой.

Убунтопроблемы.

В твоей убунте ман кривой.

и dpkg тоже кривой:

dpkg --add-architecture i386 dpkg: ошибка: неизвестный параметр --add-architecture

убунтомаинтейнеры накосячили? в дебиане гладко?

Чета кривой dpkg

эта опция употребляется с командами, например c -i

franchukroman> В твоей убунте ман кривой.
GotF> Убунтопроблемы.

LOL

убунтомаинтейнеры накосячили?

убунтомаинтейнеры собирают как и положено из транка, а не бранча

ACTIONS
       -i, --install package-file...
...
       --foreign-architecture architecture
              Add  architecture to the list of architectures for which packages can be installed without using --force-architecture, in addition to the architecture dpkg is built for (i.e.: the out‐
              put of --print-architecture).

вы неправы, это экшн

dpkg --print-architecture 
amd64

это либо дебианщики либо убунтологи накосячили

вы неправы, это экшн

/* This table has both the action entries in it and the normal options.
 * The action entries are made with the ACTION macro, as they all
 * have a very similar structure. */
static const struct cmdinfo cmdinfos[]= {
  ACTION( "install",                        'i', act_install,              archivefiles    ),
...
  { "foreign-architecture", 0, 1, NULL,         NULL,      set_foreign_arch, 0 },
...

конечно экшн, расскажи это авторам dpkg, а то они в коде прописали другое

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

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