Сайт | Скачать | Видео | Wiki

Автор Тема: Обсуждение методики сборки PRA  (Прочитано 30083 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн sfs

  • Администратор
  • Ветеран
  • ****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Обсуждение методики сборки PRA
« : 29 Август 2013, 13:58:34 »
Какой смысл в модулях?
Каждый может себе собрать дистр как из кубиков (не узнав, что такое pacman)
Подгрузка нужного  уже оптимизированного модуля из инет
Если весь дистр в памяти - догрузил туда же модуль - сделал что хотел - выгрузил
Хочешь собрать что-то другое - грузи только модули base X - и собирай
Вообще главная тема frugal - остальное следствия
В системе при таком подходе де факто имеется 2 пакетных менеджера, что приводит к свалке.
sfs-get- менеджер модулей. Задачи разные
(Тут бы уместно вспомнить о такой крутой штуке как ZeroInstall, но... оно реализовано на питоне.)
Чем он хорош?

openbox:
Еще плюсы - меню без костыля fixmenu
Минус - нет своей панели. Хотя если сплюсовать, все что мы напихали в панель jwm - возможно другая панель (может и Ваш lxpanelx) будет легче

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #1 : 29 Август 2013, 15:07:40 »
Каждый может себе собрать дистр как из кубиков
Это называется "управление пакетами"...
Подгрузка нужного  уже оптимизированного модуля из инет
...а это — "установка из репозитория".

Итого имеем два пакетных менеджера и два несовместимых формата репозиториев.


Если весь дистр в памяти - догрузил туда же модуль - сделал что хотел - выгрузил
Это конечно очень странный юзкейз, но если вы считаете его актуальным, было бы интересно узнать, чем pacman не подходит для его реализации?

Хочешь собрать что-то другое - грузи только модули base X - и собирай
Опять таки, это задача управления пакетами.

(Тут бы уместно вспомнить о такой крутой штуке как ZeroInstall, но... оно реализовано на питоне.)
Чем он хорош?
Унифицированная установка прикладного ПО под любую ABI-совместимую систему, не конфликтующая с системным пакетным менеджером, и при этом способная учитывать зависимости как между собственными пакетами, так и зависимости от системных пакетов.
Каждый пакет ставится в собственный префикс, ситуация конфликта файловых путей не возникает в принципе.
Любой пакет имеет уникальный URL. Фактически, в системе нет этапа установки пакета в явном виде (поэтому и "zero install"), приложение можно запустить командой "0launch URL", после чего если этого приложения еще нет в кэше, оно автоматически скачивается с заданного URL (и автоматически скачиваются зависимости).
Кэш может быть как локальным для пользователя так и общесистемным с целью экономии дискового пространства в многопользовательской системе.
Пользователь может вмешивать в алгоритм резолвинга зависимостей при необходимости ("а вот эту зависимость бери из вот такого моего локального репозитория вон там", "а вот эту зависимость определяй по наличию такого-то пакета в системном менеджере пакетов").
Приложения могут свободно устанавливаться пользователем, но при этом установленное приложение защищено от случайной или целенаправленной модификации: пользователь может только читать и исполнять файлы установленного пакета, но не изменять.
Ну и так далее, там много фич.

На текущий момент один из существенных недостатков -- отсутствие возможности без костылей пакетировать ПО с плагинами. На мой взгляд, этот недостаток критический. Разработчик обещает реализовать эту фичу в будущем.

Лет через 5, когда можно будет уже не поморщившись положить питон в live-образ, можно будет воспользоваться в полной мере этой технологией. Как раз все нужные фичи к тому времени реализуют.


openbox:
Еще плюсы - меню без костыля fixmenu
Минус - нет своей панели.
Лично для меня как для пользователя и разработчика это не плюсы и не минусы. WM должен управлять окнами. А меню приложений и панели не по его части.
« Последнее редактирование: 29 Август 2013, 15:16:27 от geekless »

Оффлайн sfs

  • Администратор
  • Ветеран
  • ****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Обсуждение методики сборки PRA
« Ответ #2 : 29 Август 2013, 15:26:41 »
Итого имеем два пакетных менеджера и два несовместимых формата репозиториев.
Тут можно было бы поспорить про терминалогию и отличия, но это не важно
Основная идея PRA - frugal. Как это реализовать без squashfs модулей - не знаю
В Арче с frugal все плохо. В дефолтном ядре даже aufs нет.
Зато в full arch возможно "не было печали, да апдейтов накачали". Тут то frugal и пригодится - наэкспериментировался - перезагрузился - чистая система

А чем плохо 2 ПМ? Если пакеты совместимы.
pacman никогда не будет работать с pfs
Мы никогда не напишем pfs-pacman
Какие остаются варианты?

Оффлайн Pro

  • Модератор
  • Ветеран
  • ****
  • Сообщений: 10737
  • Репутация: +113/-2
Обсуждение методики сборки PRA
« Ответ #3 : 29 Август 2013, 16:14:10 »
Цитата
Цитата
Цитата: sfs от Сегодня в 20:58:34
Хочешь собрать что-то другое - грузи только модули base X - и собирай
Опять таки, это задача управления пакетами.
ну да, но сколько же тем на форумах "хочу минималистический дистриб чтобы потом свое навешать", а тут вот оно, нада консоль? удали из образа 1-2 файла. Надо свой софт накидать - выбери  уровень нужный (консоль, чистый xorg или xorg+wm)добавляй все что заблагорассудится. Но при этом откат на дефолтную систему банально удалить несколько файлов (в обычных дистрибутивах удаление пакетов не удаляет хвосты, а давным давно и ненужные зависимые пакеты тоже не удаляло). Соответственно имеем проблему- система всегда растет при "играх" с пакетами, что печалит.

При этом, в данном случае репозитарии arch это как "шведский стол" в ресторане (я щас на отдыхе в санатории) масса софта, причем достаточно свежего.

Применительно к составу софта, уже вроде как дефолтный комплект отработан, определены задачи которые он должен выполнять(муки выбора программы для сетевых подключений не в счет, это нормальный процесс), при этом оставаясь минимального размера.  Остальные лезвия швейцарского ножа должно делать сообщество, а базовую систему - разработчики, которые не должны разбегаться при первых признаках возникающих проблем, а искать и находить решения.
Я загружаю новые пакеты сюда: http://file.puppyrus.org/users/ а дальше можно найти самостоятельно.

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #4 : 29 Август 2013, 16:26:39 »
В дефолтном ядре даже aufs нет.
Естественно, оно же ванильное. Но у вас вроде используется сборка Постфактума.

А чем плохо 2 ПМ?
Если всегда-всегда пользоваться только pfs-оверлеями, то ничем, т.к. это фактически означает использование только одного пакетного менеджера. Однако вы пишете, что pacman используется, как минимум, для подготовки образов и/или перепакетирвоания софта.

Если пакеты совместимы.
В каком смысле они совместимы, если pacman не будет знать о софте, установленном при помощи оверлея? Или будет?

Мы никогда не напишем pfs-pacman
Какие остаются варианты?
Что такое "мы никогда"? У всех присутствующих есть две руки, две ноги и голова. Я ж не попросил вас реализовать алгоритм вывода типов Хиндли - Милнера на Брейнфаке. :)

Варианты на самом деле есть. Чисто в качестве proof of concept, даже без доработки софта можно было бы заставить механизм работать с оверхедом и костылями. Чтобы работало без оверхеда и костылей, требуется минимальная допилка pacman-а. Получилась бы очень красивая система, в которой свободно можно смешивать сжатые оверлей и обычные пакеты. Вообще интересная задача. Жаль, я не могу захапать себе сразу все интересные задачи в мире. :D

Но если вас всё устраивает, пусть так остаётся.

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #5 : 29 Август 2013, 16:38:16 »
в обычных дистрибутивах удаление пакетов не удаляет хвосты
Два слова: вы ошибаетесь.  :) Соответственно, и вывод получается ошибочным. Но вообще я не об этом хотел сказать.

Идея овелеев имеет право на существование в тех случаях, когда нам нужно одним движением получить систему в четко известном состоянии. А это: публичные компьютеры, рабочие станции в организациях, некоторые виды серверов и т.п. Однако в этом случае крайне желательно, чтобы там всё-таки был полноценный ПМ для управления всем этим. Иначе админ поматерится-поматерится, а потом поставит "обычный дистрибутив".

На мой взгляд, в данном случае наличие одной единcтвенной фичи отделяет потециально очень востребованный дистрибутив от "еще одна Puppy-образная система, про которую слышали всего человек 100 во всём рунете". Потому что вы тут случайно изобрели идею "стабильного Арча" (что с чем надо скресить, чтобы оно получилось), а это ж вечная мечта кучи народа.

Оффлайн sfs

  • Администратор
  • Ветеран
  • ****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Обсуждение методики сборки PRA
« Ответ #6 : 29 Август 2013, 17:30:28 »
Да, у нас используется сборка Постфактума.
Я так и не понял чем плохо 2 ПМ...
Пользователь может манипулировать только модулями. Может pacman. А может и AUR ABS
Все зависит от подготовки и задач

Создание модуля.pfs pacman-ом- не совсем перепакетирование
Базовые модули совместимы с pacman (сохранено /var/pacman и dev компоненты)
В обычных софт.pfs удаляется все не нужное для обычной работы.
Если удаляется и DEV информация - лучше удалить и /var/pacman. Тогда pacman перестает видеть эти пакеты
Но они остаются "родными" и не ломают систему

Даже если мы напишем pfs-pacman (не знаю как без С программистов) - придется переконвертировать всю арч репу в .pfs
Зачем этот титанический труд?
На мой взгляд, в данном случае наличие одной единcтвенной фичи отделяет потециально очень востребованный дистрибутив от "еще одна Puppy-образная система, про которую слышали всего человек 100 во всём рунете".
Вы имеете ввиду полноценный pfs ПМ?
Без своей репы чем это увеличит востребованность?
Потому что вы тут случайно изобрели идею "стабильного Арча" (что с чем надо скресить, чтобы оно получилось), а это ж вечная мечта кучи народа.
Стабильный это A.R.M http://forum.puppyrus.org/index.php/topic,13966.msg80292.html#msg80292
У нас скорее неубиваемый

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #7 : 29 Август 2013, 18:36:27 »
Сейчас выдам нефильтрованный мыслепоток.  ;D

Даже если мы напишем pfs-pacman (не знаю как без С программистов) - придется переконвертировать всю арч репу в .pfs
Зачем этот титанический труд?
Во-первых, не придётся. Во-вторых, это делается автоматически.

Суть в чем. Итак, вы используете сборочные утилиты арча. (Или берете собранные арчепакеты, что то же самое.) Что происходит потом...

Пакеты (ванильные от арча + специфические для PRA) + конфигурация + releng для всего этого дела = производный от Арча дистрибутив. Дистрибутив этот логически разбит на модули типа "базовая система" + "иксы" + "настроенная рабочая среда" + "LAMP" и т.п.

Этот дистрибутив даже можно в таком виде поставить через pacman и получить обычную настольную систему. В этом месте "обычные дистрибутивы" останавливаются. Но поскольку ваша идея в том, чтобы использовать оверлеи, вы не останавливаетесь. :) Модули, которые у нас имеются логически, что с ними делаем: пакеты разворачиваются в дерево каталогов и конвертируются в сжатые образы squashfs. Т.е. получаются модули уже в физическом воплощении. Конвертация выполняется полностью автоматически, тут никаких проблем возникнуть не должно.

Теперь у конечного пользователя есть выбор: использовать модульный подход с монтированием слоями или поставить пакеты традиционным способом.

Однако. Хотелось бы иметь единую точку управления конфигурацией системы. Пока у нас были только пакеты, ею был пакман. Теперь у нас черт знает что: кто-то отвечает за монтирование слоёв, кто-то отвечает за обновление модулей (если вообще кто-то будет за это отвечать), плюс еще можно поставить пакмановские пакеты поверх...

А выход следующий: надо научить пакмана понимать, что образ squashfs — это такой особый формат пакета. В этом случае на плечи пакмана снова можно возложить все задачи управления конфигурацией:

Когда пользователь делает "pacman -S какой-то-модуль", pacman:
* Ищет файл модуля в кэше.
* Автоматически скачивает его, если его нет.
* Видит, что это образ squashfs:
* * Монтирует его во временный каталог, читает из него данные о входящих в его состав пакетах, размонтирует. Регистрирует в своей базе данных установку одного виртуального пакета, который предоставляет (provides) все имена пакетов, из которых был собран этот модуль.
* * Делает симлинк на образ в специальном каталоге, указанном в настройках. Данный каталог служит местом, где перечисляются все установленные и смонтированные модули.
* * Запускает указанную в настройках команду для обновления слоёной точки монтирования.

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

При этом если даже кто-то хочет закатать в образ пакеты не арчевского происхождения, достаточно поместить в модуль немного метаинформации чтобы пакман признал его за "своего". Таким образом отслеживание зависимостей между всеми компонентами системы будет идти через единую базу данных.

Оффлайн imago31

  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 2835
  • Репутация: +41/-0
  • горний арол
Обсуждение методики сборки PRA
« Ответ #8 : 29 Август 2013, 18:45:19 »
воют читаю и мне уже становиться страшно, система фругал, тоесть система запакованная в сквош модуль, который грузится в память в режиме для чтения, НЕУБИВАЕМАЯ СИСТЕМА, все изменения отдельно в файл, в папку, в модуль, зачем терять все ето!? Система обязана и должна быть модульной! ето тоже самое что взять и поменять свою веру!
 На мой взгляд должен быть сайт с готовыми pfs МОДУЛЯМИ, как ето сделано в pr13.ox, или тотже sfs-get, также должна оставаться возможность собирать модули самому для более опытных пользователей, ну а наличие пакетново менеджера pacman или какой там еще не мешает. Всегда можно скачать какую нибудь новую прогу, ну или вообще если кому нибудь не нужны проги в виде модулей.
 Считаю что терять модульность не стоит!
Врач спасает человека, ветеринар - человечество
 все эксперименты на dual core 2x3.1 GHz/ram-3Gb/gt 440 1gb/WCD 80gb IDE/Samsung 80gb sata/3 флешки с зоопарком линуксов.
  Для работы и игр: Windows 10 снес, поставил 7
  Для души, для скорости и всего остального: Linux(pra, puppy, porteus, ubuntu-подобные)
 
 игровые модули
 программные модули

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #9 : 29 Август 2013, 18:48:09 »
Считаю что терять модульность не стоит!
Считаю, что стоит перечитать еще раз.

Оффлайн sfs

  • Администратор
  • Ветеран
  • ****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Обсуждение методики сборки PRA
« Ответ #10 : 29 Август 2013, 19:00:35 »
С теоретической точки зрения Вы все правильно пишите, но с практической:
Скрипт pkg2pfs есть - все автоматически, но крутить его постоянно по всей репе арча ресурса нет
pacman переписывать некому. Причем это придется делать постоянно. Он за год уже раза 3 обновился
У нас уже в дистре 250 арч пакетов, а слоев aufs 128

Вместо pacman -S какой-то-модуль мы пишем sfs-get какой-то-модуль и получаем описанный Вами результат
Только трудозатраты - написать несколько sh скриптов

В PR мы компилили репу и писали ПМ. PRA - как раз "хитрый ход" избавиться от этих проблем ничего не потеряв

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #11 : 29 Август 2013, 19:04:08 »
Да как угодно. :) В таком виде дистрибутив никому не нужен, кроме посетителей этого форума, но я так понял, задачи выхода на более широкий уровень и не ставится.

Оффлайн Pro

  • Модератор
  • Ветеран
  • ****
  • Сообщений: 10737
  • Репутация: +113/-2
Обсуждение методики сборки PRA
« Ответ #12 : 29 Август 2013, 19:14:01 »
каковы реальные шансы реализовать поддержку pfs внутри pacman?

своими силами - 0 программистов нету да и форк pacman будет ли лучшим решением?
попросить разработчиков arch запилить поддержку - ?
Я загружаю новые пакеты сюда: http://file.puppyrus.org/users/ а дальше можно найти самостоятельно.

Оффлайн geekless

  • Старожил
  • ****
  • Сообщений: 240
  • Репутация: +8/-0
Обсуждение методики сборки PRA
« Ответ #13 : 29 Август 2013, 19:31:06 »
каковы реальные шансы реализовать поддержку pfs внутри pacman?

своими силами - 0 программистов нету да и форк pacman будет ли лучшим решением?
попросить разработчиков arch запилить поддержку - ?
Ну мужики, вы линксоиды или где? Я понимаю, там, "нам это не нужно, нас и так всё устраивает" -- это уважительная причина. Но "мы не можем" в линуксе уважительной причиной не является. :)

Оффлайн sfs

  • Администратор
  • Ветеран
  • ****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Обсуждение методики сборки PRA
« Ответ #14 : 29 Август 2013, 20:32:01 »
Что касается pacman pfs и меня - скорее "мне это не нужно, меня и так всё устраивает" в плане стыковки arch + frugal
Я трезво оцениваю свои силы и ситуацию. Поэтому более грандиозных планов чем "своя арч репа" нет
Это можно сделать хоть сейчас, но есть проблемы важней. Пока обхожусь локальной
"Арч будет тем, что Вы из него сделаете" - поэтому и выбрал Арч. Все по инструкции :)
Глобальные цели мало изменились с начала моего домашнего дистростроения :
хотя бы улучшение подготовленности пользователя в процессе создания и популяризация linux
« Последнее редактирование: 29 Август 2013, 20:34:10 от sfs »