Обзор реализаций поддержки мультиархитектур в дистрибутивах Linux и их сборочных системах (Константин Шевцов, LVEE-2014) — различия между версиями

== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->
* [http://lvee.org/en/abstracts/89 Страница доклада на сайте конференции]

<references/>

[[Category:LVEE-2014]]
[[Category:Open-source projects]]
[[Category:Linux]]

<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2020-07-067T203:1100:14.122619562958|vimeo_comments=0|vimeo_plays=39|youtube_comments=0|youtube_plays=18}}

Версия 20:00, 7 июля 2020

Аннотация

Докладчик

Константин Шевцов

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 не позволяет устанавливать пакеты сторонних архитектур в сборочное окружение. Чтобы решить данную проблему создан механизм 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” [1]. Существует также экспериментальный проект 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 дистрибутив, в нем существует три различных способа решения рассматриваемой задачи [2]:

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

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

ArchLinux

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

Выводы

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

Источники

Примечания и отзывы

• Страница доклада на сайте конференции

Plays:57   Comments:0