Міжнародна конференція розробників
і користувачів вільного програмного забезпечення

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

Kanstantsin Shautsou, EPAM Systems

LVEE 2013

The world is not ideal that's why some packages can't built under certain architecture (i.e. grub, wine) or some vendors doesn't produce packages (skype, steam). In future it will allow run ancient packages. For this cases all distributives has multiarch support - installing of packages from more then one architecture in one system. This article is an overview of multiarch realizations in modern GNU/Linux distributives: OpenSUSE, Fedora, Debian/Ubuntu, Gentoo, ArchLinux and describes differences in package lifecycle.

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

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

OpenSUSE

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

Fedora

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

Debian / Ubuntu

В Debian до версии 7 и в Ubuntu до версии 11.04 картина выглядит следующим образом. Большие пакеты ia32-* 8 содержат 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 дистрибутив, в нем существует три различных способа решения рассматриваемой задачи9:

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

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

ArchLinux

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

Выводы

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

Источники

1 https://build.opensuse.org/
2 https://en.opensuse.org/openSUSE:Build_Service_baselibs.conf
3 https://github.com/openSUSE/libsolv
4 http://koji.fedoraproject.org/koji/
5 https://lists.fedoraproject.org/pipermail/buildsys/2011-January/003496.html
6 https://admin.fedoraproject.org/pkgdb/acls/name/mash
7 http://yum.baseurl.org/wiki/CompareProviders
8 http://packages.debian.org/squeeze/ia32-libs
9 http://wiki.gentoo.org/wiki/Multilib
10 http://www.gentoo.org/proj/en/base/amd64/emul/emul-linux-x86-20130224.xml
11 http://wiki.gentoo.org/wiki/Gx86-multilib
12 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/wine-1.5.31.ebuild?view=markup#33
13 https://wiki.archlinux.org/index.php/Arch64_FAQ#Multilib_Repository_-_Multilib_Project

Abstract licensed under Creative Commons Attribution-ShareAlike 3.0 license

Назад