Как не перестать собирать пакеты в эпоху перемен (Виталий Липатов, OSSDEVCONF-2025)

Ссылки сюда (1) →

Короткая ссылка: 20251004D

Докладчик

Виталий Липатов

Пакеты были способом сборки и доставки, но сейчас они важны как единица установки, управляемая пакетным менеджером. Почти все современные языки (Java, Rust, Go, C#, Javascript (nodejs, electron)) не позволяют собрать приложение в пакет классическим способом (без доступа в сеть).

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

Презентация

Thesis

Ключевые слова: epm, rpm, сборка, установка приложений.

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

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

В условиях, когда в каждом дистрибутиве свой формат пакетов, свои версии библиотек (в каждой версии дистрибутива), а программы распространяются в виде исходного кода, создателям дистрибутивов ОС приходится создавать репозитории бинарных пакетов, собранных и подходящих для конкретной версии дистрибутива.

Это пошло с тех времён, когда авторы свободного софта писали инструкцию по установке в виде команды configure && make && make install, проприетарного софта практически не было, а имеющийся шёл с инструкцией по установке.

Почти все современные языки (Java, Rust, Go, C#, Javascript (nodejs, electron)) не позволяют собрать приложение в пакет классическим способом (без доступа в сеть), вынуждая использовать бинарные блобы или различные костыли.

Система сборки многих популярных приложений вообще не предполагает сборку в пакет, а отсутствие исходников (для закрытого ПО) делает такую сборку невозможной.

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

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

Возьмём к примеру клиент Telegram.

С одной стороны, путём больших усилий сообщество добилось того, что его возможно собирать в пакет из исходников штатным способом (через cmake, с использованием системных библиотек).

С другой стороны, сторонники сборки всего в репозиторий говорят: я буду пользоваться только оригинальной бинарной сборкой с сайта производителя, и загружать её буду в домашний каталог.

С третьей стороны, разработчики клиента Telegram говорят: сообщайте о багах только в оригинальной сборке, мы не поддерживаем сторонние сборки.

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

Использование бинарных сборок поднимает вопрос о несовместимости с дистрибутивом. Тут появляется требование сборки в репозиторий для системы или в формате, совместимом с дистрибутивом.

Зачастую в дистрибутивах намеренно не предусматривается обратная совместимость по версиям библиотек в стиле «это вы должны быть совместимы с нами».

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

Предложение собрать пакет с ПО под дистрибутив и выложить в виде отдельного репозитория проваливается на том, что производители изобретают свои способы сборки, всё равно пакуют собранный единожды под старую Ubuntu бинарник в разные форматы пакетов, а добавление множества репозиториев в систему делает проблемным обновление при сбое или недоступности одного из них.

В России основанные на Linux системы стали отечественными, и для них стали массово создавать закрытое прикладное ПО, культура распространения которого ещё не сформировалась.

Применяемый для распространения мессенджера MAX подход, когда для установки предлагается скачать .deb, .rpm или .AppImage, внутри которых одни и те же бинарники, пожалуй, один из лучших действующих подходов.

Всё это подводит к простой мысли, что прикладное ПО не должно сопровождаться в составе репозитория для дистрибутива ОС, а должно поставляться в виде пакета, который штатным образом установится в эту ОС. Свободный софт при этом может собираться поставщиком или для независимого от дистрибутива репозитория. Закрытый софт, как это и происходит на практике, не должен выпускаться под каждую версию дистрибутива отдельно. Дистрибутивы должны обеспечивать совместимую площадку. Сейчас движение дистрибутива к универсальности больше подменяется попытками сделать пакет, работающих на разных системах с помощью сложного установочного скрипта.

Никуда не делся вопрос с упаковкой Windows-приложений, чтобы они ставились в виде штатного пакета в систему, не отличаясь от Linux-приложения.

Для управления установкой приложений создаются системы распространения ПО внутри организации, по сути внутренний магазин приложений. К примеру, внутренняя разработка Сбера или продукт Аврора Центр. Но это специализированные решения, не подходящие для массового пользователя, которого обычно заставляют заходить на сайт, вручную скачивать какой-то файл и устанавливать его сложными действиями, к тому же ещё в несовместимый дистрибутив.

Linux перестаёт быть системой, создаваемой энтузиастами для энтузиастов, и это требует новых подходов.

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