Differences

This shows you the differences between two versions of the page.

--- stalin_repository [2024/09/13 16:38] – created uf4n
+++ stalin_repository [2024/09/16 19:46] (current) – uf4n
@@ Line 1: / Line 1: @@
-====== StaLin - Репозиторий для сборки пакетов ПО без внешних зависимостей ======
+====== VyatLUG - Репозиторий для сборки пакетов ПО без внешних зависимостей ======
+===== Концепция =====
+VyatLUG - это репозиторий пакетов исходных кодов, подготовленных для сборки бинарных файлов со статической линковкой. Из каждого пакета, включённого в этот репозиторий, должны автоматически собираться бинарные deb и rpm пакеты. За данную задачу отвечает программа StaLin.  Оптимальный формат для пакетов исходного кода - предмет исследования, однако для начала это может быть обыкновенный тарбол.
+Самостоятельные программы должны быть написаны на языках Си и Си++, причём код библиотек должен быть включён в дерево исходного кода каждой программы, благодаря чему при сборке можно обойтись без cmake/autotools. Единственная допустимая run-time зависимость для любой программы в системе - ядро. Недопустимы программы на скриптовых языках,, а также на языках, с экосистемой, представляющую из себя комбаин для разрешения зависимостей между библиотеками разных версий, к тому же качающий их с серверов корпораций, желающих одного - подсадить разработчика на свою иглу. Гудбай, Python, Rust, Go и прочий маздай.
+Так как сборка любой программы в простейшем случае будет выполняться одной лишь командой make, правила для сборки бинарного пакета (будь то deb или rpm) получаются очень простыми и ещё проще, когда любого рода зависимости (Requires, Conflicts etc) запрещены.  Конфликты не должны восприниматься как зависимость: если два пакета предоставляют одну и ту же возможность, пользователь сам делает между ними выбор, разрешая конфликт вручную. Автоматическая генерация spec-файлов будет проходить очень просто, на основе общей для deb и rpm информации о пакете, такой как имя программы, версия, релиз, вендор и т. п. Эту информации можно хранить в пакете исходного кода в виде текстового файла.
+Такой подход к сборке бинарних пакетов ПО позволит:
+. Избежать ада зависимостей (dependency hell), который предполагает:
+ a. необходимость разрешения длинных, циклических и конфликтующих зависимостей
+ b. необходимость обновлять те программы, в обновлении которых у пользователя нет объективной потребности. Например, из-за того, что старая версия программы стала несовместимой с новой версией разделяемой библиотеки, которая подтянулась в качестве зависимости при установке другой программы
+. Легко переносить ПО на любую аппаратную платформу благодаря переносимости кода на Си/Си++
+. Собирать ПО с максимальной возможной оптимизацией машинного кода, использую соответствующие параметры компилятора при сборке конечных бинарный deb или rpm пакетов. Гудбай, Генту - дистрибутив с пакетным менеджером, написанным на Python, который как пить дать перекомпилирует тебе половину пакетной базы перед установкой одной новой программы.
+. Ликвидировать зоопарк дистрибутивов, использующих разные высокоуровневые пакетные менеджеры.
+. Предать забвению flatpak, snap etc.
+===== Фронт работ =====
+  * Посмотреть дистрибутив Stali от Suckless.org