Обзор реализаций поддержки мультиархитектур в дистрибутивах Linux и их сборочных системах

По мере появления новых архитектур компьютеров стали появляться дистрибутивы собранные под эти архитектуры. По ряду причин не все программы под GNU/Linux существуют и могут работать под родной архитектурой системы: так например wine и grub не могут быть собраны под архитектуру x86_64, а некоторые закрытые программы, например skype и steam, поставляются собранные только под x86. Поэтому дистрибутивы начали приспосабливать свои пакетные менеджеры и сборочные системы. Способ совмещения пакетов двух разных архитектур в одной установке называется как multiarch или bi-arch.

Рассмотрим как эта ситуация решается в ряде наиболее распространенных дистрибутивов. В качестве ярко выраженного примера рассмотрим сборку и установку gcc с поддержкой multilib (-m32 & -m64 build flags) для x86_64.

OpenSUSE

Используемая в дистрибутиве сборочная система OBS ¹ не позволяет устанавливать пакеты сторонних архитектур в сборочное окружение. Чтобы решить данную проблему создан механизм baselibs ² — перепакетировка содержимого пакета одной архитектуры в другую. Например, x86-пакет с именем foo после сборки дублируется в foo-32bit с архитектурой x86_64 (модификация имени и архитектуры в метаинформации пакета). Далее такой пакет копируется в x86_64-репозиторий, и этот репозиторий целиком паблишится для пользования конечным пользователем. Пути размещения библиотек — /lib32 и /lib64. Дистрибутив использует пакетный менеджер rpm/zypper, а для расчета зависимостей применяется libsolv ³.

Fedora

Сборочная система Koji ⁴ также не позволяет смешивать архитектуры в buildroot’e. Для удовлетворения сборки x86_64 multilib gcc, grub применяется спрятанный пакет-заглушка glibc32 ⁵, который содержит 32-битные библиотеки. Файлы сборки (.spec) написаны так, чтобы при установке rpm-пакеты библиотек и заголовочных файлов двух архитектур не конфликтовали в одной системе. Пакетный менеджер Yum понимает архитектуры “pkgname.arch”. Для конечного пользователя предоставляется один репозиторий, содержащий выборку пакетов из двух архитектур (для паблишинга используется утилита mash ⁶). Пути укладки библиотек — /lib32 и /lib64. Используется пакетный менеджер rpm/yum, а расчет зависимостей выполняется yum “compare_providers” ⁷. Существует также экспериментальный проект rpm/Hawkey/DNF с использованием libsolv.

Debian / Ubuntu

В Debian до версии 7 и в Ubuntu до версии 11.04 картина выглядит следующим образом. Большие пакеты ia32-* ⁸ содержат x86-библиотеки и имеют архитектуру x86_64. Их неудобно поддерживать, типичен очень большой размер (порядка 33 МБ), а версия пакета обычно представляет собой дату сборки.

Начиная с версии 7 в Debian и версии 11.04 в Ubuntu добавлена поддержка различия архитектур установки “pkgname:arch” для dpkg/apt-get. Сборка происходит в buildd, добавлено новое поле в сборочных файлах Multi-arch. Но для сборки по-прежнему используются пакеты lib32*. Пути установки имеют вид prefix/lib/triplet (т.е. происходит игнорирование FHS). Пакетный менеджер по-прежнему dpkg/apt-get (или aptitude).

Gentoo

В связи с тем, что это source-based дистрибутив, в нем существует три различных способа решения рассматриваемой задачи⁹:

1. Изначальный способ – это большие пакеты emul-linux-* x86_64 ¹⁰, содержащие файлы с архитектурой x86.
2. Существует также проект gx86-multilib ¹¹ c eclass’ами, которые добавляют архитектурные USE-флаги (abi_x86_32, abi_x86_64), управляющие зависимостями. Использование этого подхода требует изменения текущих ebuild’ов, например wine ¹².
3. Форк multilib-portage позволяет собирать пакеты сразу под нужные архитектуры без модификации ebuild’ов.

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

ArchLinux

Данный дистрибутив имеет отдельный репозиторий multilib ¹³, в котором собираются пакеты с архитектурой x86_64, именем пакета lib32-* и x86-содержимым. Пакетный менеджер — pacman.

Выводы

Таким образом видно, что у большинства дистрибутивов первым этапом поддержки мультиархитектур было простое добавление x86_64-пакетов с x86-содержимым. Однако, наиболее правильным способом на данный момент видится вариант, когда содержимое пакета соответствует метаинформации пакета, а зависимости строятся с учетом архитектур, исключая конфликты путей. В дальнейшем такие улучшения должны помимо более корректного построения пакетной базы позволить миграцию между архитектурами без переустановки и возможность запуска “древних” программ старых архитектур в новых версиях дистрибутивов, что на текущий момент является актуальной и нерешенной проблемой.

Источники

¹ https://build.opensuse.org/
² https://en.opensuse.org/openSUSE:Build_Service_baselibs.conf
³ https://github.com/openSUSE/libsolv
⁴ http://koji.fedoraproject.org/koji/
⁵ https://lists.fedoraproject.org/pipermail/buildsys/2011-January/003496.html
⁶ https://admin.fedoraproject.org/pkgdb/acls/name/mash
⁷ http://yum.baseurl.org/wiki/CompareProviders
⁸ http://packages.debian.org/squeeze/ia32-libs
⁹ http://wiki.gentoo.org/wiki/Multilib
¹⁰ http://www.gentoo.org/proj/en/base/amd64/emul/emul-linux-x86-20130224.xml
¹¹ http://wiki.gentoo.org/wiki/Gx86-multilib
¹² http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/wine-1.5.31.ebuild?view=markup#33
¹³ https://wiki.archlinux.org/index.php/Arch64_FAQ#Multilib_Repository_-_Multilib_Project