1. Релизная модель и версионирование.
Релизная модель: стабильные релизы с опциональными обновлениями.
Номер версии можно представить в следующем виде: YYYY.SU.R, где:
YYYY- номер мажорного выпуска дистрибутива. Формируется по году выпуска дистрибутива. В рамках мажорного выпуска фиксированы ключевые особенности дистрибутива, такие как поддерживаемый пакетным менеджером набор фич (формат пакетов).SU— номер system update. В рамках одного номера system update фиксированы минорные версии библиотек и других системообразующих компонент. При переходе на следующий system update минорные версии могут меняться с сохранением обратной совместимости ABI.R- номер корректирующего выпуска с исправлениями багов и закрытием уязвимостей.
В применениях, где требуется максимальное сохранение стабильности ABI, следует использовать выбранную ветку YYYY.SU и не переключаться на другие SU.
В применениях, где требуются наиболее актуальные версии библиотек при сохранении разумного уровня совместимости ABI (но с учётом вероятности его непредумышленной поломки апстримом или других непредусмотренных факторов), имеет смысл обновляться на новые SU по мере их выхода.
Как отдельные ветки SU, так и мажорный выпуск YYYY в целом, поддерживаются до тех пор, пока есть энтузиасты, готовые заниматься сопровождением. Понятие «перевода дистрибутива в архив» не существует. Любая сколь угодно старая ветка может получить корректирующие апдейты или новые SU при условии, что есть желающие сформировать апдейт, он соответствует критериям качества, а также есть ответственные лица, которые могут провести оценку по этим критериям.
2. Система сборки и пакетирования.
Для пакетирования применяется система, подобная Arch/Alpine/Void: то есть дерево портов со сборочными рецептами на shell. Однако процедура сборки более формализована.
Существует три уровня организации рецептов сборки.
На первом уровне хранятся сборочные рецепты для пакетов в наиболее общем виде.
На втором уровне они детализуются различными опциями сборки. Например, из одного исходного пакета может собираться несколько вариантов программы под разные тулкиты, с разными включенными флагами сборки и т.п.
На третьем уровне сборочные зависимости точно специфицируются в привязке к состоянию репозитория собранных пакетов конкретной ветки дистрибутива. Это позволяет при необходимости повторить сборку пакета в идентичных условиях с абсолютно идентичными зависимостями.
После полной спецификации сборочного рецепта, он поступает на обработку сборочной фермой, которая воспроизводит указанное состояние сборочной среды и собирает пакет. Для сборки пакетов пользователем локально должна быть предоставлена точно такая же возможность из коробки, не требующая дополнительных усилий по настройке. Сборка пакетов в формально специфицированной изолированной среде должна быть режимом по умолчанию, а не опцией, требующей отдельного конфигурирования.
Полностью специфицированный сборочный рецепт включается в состав финального пакета. Таким образом конечный пользователь всегда и без дополнительных скачиваний чего-либо имеет доступ к рецепту, чтобы понимать, как и чем именно собран пакет, и может при необходимости пересобрать его с собственными правками или флагами компилятора. Если при сборке пакет разбивается на суб-пакеты, то сборочный рецепт прикладывается к каждому из них.
Для ран-тайм зависимостей используется указание, максимально приближенное к «реальному состоянию дел». Например, если приложение динамически слинковано с libjpeg.so.8, значит именно libjpeg.so.8 будет указан в зависимостях пакета. А если точнее, то в качестве зависимости указывается PLATFORM:libjpeg.so.8, где PLATFORM - один из вариантов платформы, поддерживаемой дистрибутивом (ближайший аналог спецификатора multiarch в Debian).
Также ран-тайм зависимости более точно указывают на конкретные версии интерпретаторов и сред исполнения. Например, возможно бесконфликтное существование нескольких веток python 3.x с отдельными наборами библиотек.
3. multiarch и multiOS
В дистрибутиве возможно параллельное существование нескольких вариантов /usr/lib под разные ABI, подобно тому, как это реализовано в Debian. Кроме того, этот подход может быть расширен для поддержки разных ядер операционных систем за пределами Linux, таких как NetBSD или сборка пакетов для cygwin-подобного ран-тайма под WinAPI.
4. portable-сборки и развертывание пакетов без админского доступа.
В метаинформацию пакета включена информация о том, может ли он быть установлен и использоваться по произвольным путям или же привязан к конкретным путям.
Пользователь может устанавливать пакеты локально в своей учётной записи, при условии, что пакеты не привязаны к путям, а также не требуют особых привилегий для установки и работы.
Также возможна автоматическая конвертация portable-пакетов в пакеты системы Zero Install, что позволяет устанавливать их на любой мейстримной Linux-based ОС.
5. Декларативная конфигурация системы
По возможности, пакеты вообще не должны содержать никаких установочных скриптов.
Если установка пакета требует чего-то большего, чем простая распаковка архива, то такая конфигурация должна быть задана декларативно и отработана хуками пакетного менеджера.
Например, в Arch сейчас всего менее 400 пакетов имеют install-скрипт. Это полная противоположность скриптового хаоса в Debian-based дистрибутивах, где это количество измеряется тысячами. Из этого количества в 400 штук - около половины просто выводит сообщение пользователю. Из оставшихся больше половины вызывают команды типа setcap/chmod/chown для конфигурирования прав доступа и привилегий для пакета. Все эти действия могут быть заданы декларативно. Еще часть пакетов содержит избыточные команды, которые и так обрабатываются хуками ПМ.
В идеале установочные скрипты должны сохраниться только у нескольких ключевых системных пакетов, которые выполняют нетривиальные действия по конфигурации системы при установке дистрибутива.
6. Отсутствие неявной «автоматической» конфигурации системы
Пакетный менеджер ставит пакеты. Он не запускает демоны, не настраивает конфиги в /etc, не правит симлинки. Он устанавливает и удаляет пакеты предсказуемым образом с целью сохранения воспроизводимого состояния системы.
Также это подразумевает отсутствие какого-либо --install-recommends. Ставятся только жесткие зависимости пакетов, и они же удаляются при рекурсивном удалении. Управление дополнительными компонентами может выполняться пользователем самостоятельно.
С целью более удобного управления пакетами, в ПМ должна быть предусмотрена возможность для пользователя оставлять и просматривать локальные комментарии для пакетов. Чтобы пользователь мог написать для пакета заметку вида:
# apt comment 'libblabla-git' 'Установил версию прямо из github как makedep для progfoobarbaz'
7. Политика сборки пакетов.
При сборке пакетов они воспроизводятся настолько близко к апстриму, насколько возможно. На исходники могут накладываться только патчи с закрытием уязвимостей и исправлениями багов. Никакая самодеятельность в накладывании патчей, произвольно меняющих поведение ПО, изменяющих конфиги по умолчанию и т.п., недопустима. Патчи-блобы на тысячи строк кода, делающие непонятно что, недопустимы. Однако допустимы патчи, приводящие структуру установочных путей программы в соответствие с требованиями дистрибутива или патчи для формирования portable-сборок, не привязанных к установочным путям.
Энтузиасты, однако, могут поддерживать кастомные варианты пакетов с патчами, меняющими настройки и функциональность программ. Суть таких пакетов должна быть явно видна из их названия и описания. Например: linux - ядро Linux; linux-zen - ядро Linux, собранное с патч-сетом zen.
8. Особые возможности дистрибутива
Исключение из предыдущего пункта составляют сильно пропатченные версии системных компонент, которые реализуют особые фичи дистрибутива. В частности:
- Вынос логики nsswitch в отдельный системный демон. glibc больше не занимается ничем, что связано с nsswitch. Она просто коннектится к демону и запрашивает у него необходимую информацию. Аналогичная поддержка должна быть также внедрена в musl. Статические программы теперь могут быть действительно статическими. А логика работы nsswitch изолирована за платформенно-независимым протоколом и отвязана от ABI прикладного кода.
(Пока только один пункт)
9. systemd или openrc, glibc или musl
Ответ: и то, и другое, при наличии энтузиастов, готовых поддерживать соответствующие ветки дистрибутива. Однако если кто-то делает ветку без systemd, значит отказ от systemd должен быть полным. Никаких костылей в виде elogind. Только ConsoleKit2 вместо него. Кроме того, использование средств, отличных от systemd, не должно вредить возможностям декларативной конфигурации системы.
