Обсуждение методики сборки PRA

[sfs]

Актуальнее конвертнуть наши довесочные pfs в pkg. Если это будет сделано - можно будет собирать дистр в автоматическом режиме хоть каждый день
Если не заморачиваться загрузкой всей системы в память и иметь сохраненку в раздел или дир. - получится почти full
pacman -Syu и вся система обновилась. То же и с установкой софта. Сделал копию дира сохраненки - забэкапился. Всегда можно откатиться.
Таким образом можно тестить все новое и не бояться сломать

C pacman2pfs вряд ли у кого-то возникнет проблема с изготовлением модулей. Все выкачает с зависимостями и почистит лишнее.  Этот скрипт надо доводить в 1ю очередь. Может и gui приделать...

[Zay]

Получается есть два возможных пути разработки PRA:

1. Практически стандартный Arch дистрибутив с добавленным специальным функционалом (установка в файл а не в раздел, подключение SFS/PFS и т.д.).
Технические отличия от Arch - ядро с AUFS, специальный Initrd и несколько доп. пакетов PKG.

2. Собственный дистрибутив, собираемый PFS-пакетов и максимально полно совместимый с Arch (с возможностью использования бинарных пакетов Arch, в т.ч. и для сборки системы).
Технические отличия от Arch более значительные - другой основной тип пакетов со всеми вытекающими особенностями.


Лично мне второй вариант кажется более перспективным.
Преимущества:

Формат пакетов PFS изначально оптимизирован для Frugal, он значительно удобнее PKG при таком режиме установки.
Если формат PFS будет основным - то получится сохранить привычный в Puppy подход к программам "Подключил - Использовал - Отключил".
Собственный (пусть и упрощенный) менеджер пакетов (именно пакетов, не модулей).
Связь с Arch при таком подходе будет не такая жесткая, при большой необходимости можно будет перейти на другую основу.

Конвертировать всю репу Arch-а в PFS заранее при таком подходе не нужно. Это можно делать прозрачно с помощью скрипта (например pacman2pfs).
Pacman в этом случае можно использовать исключительно из скрипта для закачки пакетов с зависимостями с последующей автоматической конвертацией в PFS.
Остальной функционал Pacman-а - лишний в Frugal системе (ИМХО). Если хочется обновлять систему одной командной - лучше поставить обычный Arch.


ИМХО, на этом этапе нужно определиться, по какому направлению будет идти разработка PRA!

[Pro]

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

[sfs]

Я за 1й вариант. И далее своя pkg репа. В этом и была первоначальная задумка. Это нормальная интеграция в арч, без потери своего лица. Постепенный переход к только pacman сборке модулей с подключением своей pkg репы. Причем это можно делать настолько постепенно , насколько хочется.

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

1 вариант это тоже позволяет. Только зачем это нужно? Практика показала, что пересобирать надо раз в 3 месяца (если сидеть на нормальной,  а не https://bbs.archlinux.org/viewtopic.php?pid=1316243 ветке).
2й вариант - это шаг назад.
PRA уже вполне рабочий. Если пойти по 2му пути - сразу вязнем в проблеме переконвертации пакетов , их размещения и доработки pfs-util. Причем работа останавливается до завершения этих процессов. Т.е. то, на чем затормозился PR.
В чем тогда новизна подхода? Через пол года получим 2й PR который или "любить таким какой он есть пока морально не устареет" или "до основания , а затем..."

Причем на выходе 1 и 2 - тот же дистр, т.к. собирается из тех же файлов
Зачем ходить кругами: переконвертация репы, изготовление из pfs-util pacman-а. И сразу вопрос - кто и как готов этим заниматься? В какие сроки сделает? Если никто - что мы обсуждаем?

[Pro]

логично.
zay, твое мнение?

[sfs]

pfs-util в PRA используются и будут использоваться. Для работы с модулями - это лучшее что есть
Там есть что дорабатывать. Скачка и работа с зависимостями не помешают в виде: подключил модуль с прогой - подключалка доставила pacman2pfs недостающее и предложила pfsmerge с модулю
Переконвертация репы - пустая трата времени. Писать полноценный ПМ на bash под ни с кем не совместимый формат пакетов - тоже.

[Zay]

Если пойти по 2му пути - сразу вязнем в проблеме переконвертации пакетов...

Переконвертация репы - пустая трата времени

Ну я уже несколько раз писал что не нужно конвертировать пакеты!
Достаточно доработать pacman2pfs (или аналог).

А в будущем небольшой свой репозиторий в любом случае нужен, PKG или PFS.

Т.е. то, на чем затормозился PR.

На чём затормозился PR конкретно?

Через пол года получим 2й PR который или "любить таким какой он есть пока морально не устареет" или "до основания , а затем..."

Во втором варианте - не получим, т.к. все пакеты PFS будут автоматически собираться из пакетов Арча, кроме своих доработанных. Т.е. обновление системы будет зависеть от репозитория Арча.
А в теперешнем варианте - как раз вполне возможно придётся переделывать всё с нуля, когда доработанные вручную пакеты Арча будут обновлены, и т.д. "PRA уже вполне рабочий", но нормального механизма обновления (без серьезной ручной доработки) я не вижу. Как раз получается "пока не устареет", а потом и "до основания".

...пустая трата времени. Писать полноценный ПМ на bash под ни с кем не совместимый формат пакетов - тоже.

Формат пакетов PFS на сегодня - уникальный. В среде Frugal этот формат - наиболее удобный, как показала теория и практика.
Тут есть за что бороться. Тем более что значительная часть функционала ПМ в PFS-utils уже реализована.


Поэтому я за 2-й вариант.
Арч-образный дистрибутив с несколькими "плюшками" и костыльно прикрученным PFS, как мне кажется, не имеет перспективы развития.
А вот дистрибутив из бинарных файлов Арча, но собранный из пакетов PFS - более перспективная идея. ИМХО.

[geekless]

Мне кажется, первый вариант более удобен для мейнтейнера системы. Думаю, sfs прав.

[sfs]

Ну я уже несколько раз писал что не нужно конвертировать пакеты!
Достаточно доработать pacman2pfs (или аналог).

Что-то запутался. Сборка
1й вариант: pacman+своя репа pkg+trim=pfs
2й вариант: pacman+pkg2pfs=pfs1,pfs2,pfs3,... ;  pfs1,pfs2,pfs3,... +своя репа pfs+pfsmerge=pfs
Так?
На выходе одинаковый результат. Зачем лишний круг ?

А в будущем небольшой свой репозиторий в любом случае нужен, PKG или PFS.

pkg репа уже есть. Выложен в шапке. Пока подключаю локально. Нужен только при сборке базовых pfs.
pfs репа для sfs-get тоже есть.

На чём затормозился PR конкретно?

Вот

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

Чтобы дистр не устарел обновление компонентов необходимо не зависимо от формата пакетов
PRA пересобирается с нуля за час. Это вообще не проблема. Делать это целесообразно не чаще раз в 3 месяца

нормального механизма обновления (без серьезной ручной доработки) я не вижу.

Вот
Когда все наше будет в pkg репе - вот

Формат пакетов PFS на сегодня - уникальный. В среде Frugal этот формат - наиболее удобный, как показала теория и практика.

Планов отказаться - нет. Злоупотреблять - тоже.
Если даже появится скачка и зависимости - как без репы?
Тут есть за что бороться. Тем более что значительная часть функционала ПМ в PFS-utils уже реализована.

Поэтому я за 2-й вариант.

Что конкретно Вы готовы для этого  сделать и в какие сроки?

Арч-образный дистрибутив с несколькими "плюшками" и костыльно прикрученным PFS, как мне кажется, не имеет перспективы развития.
А вот дистрибутив из бинарных файлов Арча, но собранный из пакетов PFS - более перспективная идея. ИМХО.

В чем перспектива? "От перемены мест слагаемых сумма не меняется"
Глобальная перспектива - своя pkg или AUR репа.

[RoDoN]

1. Практически стандартный Arch дистрибутив с добавленным специальным функционалом

2. Собственный дистрибутив, собираемый PFS-пакетов и максимально полно совместимый с Arch

По 2-му варианту мне более-менее понятно, как дистр будет собран в модульном варианте, а вот в случае 1-го варианта мне не понятно или будет монолит после обновления системы через pacman?

[sfs]

По сути дистр арч - это список пакетов без версий: pacman -Qq
Модульность добавляет гемора.
10base собирается makechrootpkg. Без своей репы
Остальное pacman2pfs `cat список-пакетов` со своей репой
Сейчас свое приклеивается pfsmerge
По любому pfsmerge потребуется для склейки devx-ов от модулей

[Zay]

Основное преимущество PFS-utils перед другими существующими ПМ, в т.ч. и Pacman-ом - поддержка двух состояний пакета: "подключён" и "установлен".
Подключенные пакеты бессмысленно удалять, и тем более обновлять (по сути файлы тогда продублируются, в SquashFS и в сохранёнке).


Если будет реализован первый вариант - то получится ещё один дистрибутив, похожий на многие уже существующие.
Будет полностью потеряна модульность (удалить пакет, который встроен в дистрибутив нельзя никак, если удалить данные из /var - ни Pacman ни PFS-utils его не увидят).
Будет утрачен минимализм (один-два запуска Pacman - и сохранёнка раздуется до огромных размеров), работа из RAM будет невозможна.
Таким образом теряется основной смысл использования SquashFS (после обновления нескольких больших пакетов итоговый размер системы станет больше оригинала).
И получится что от PuppyRus останется только сохранёнка и подключение модулей (всё это есть в том же MagOS). А это далеко не основные удобства PuppyRus в сравнении с прочими дистрибутивами.

Что конкретно Вы готовы для этого сделать и в какие сроки?

Как минимум планирую продолжать разработку PFS-utils, добавлять функционал и устранять ошибки по мере необходимости.
Конкретных сроков, к сожалению, назвать не могу (как и почти все участники проекта), т.к. это зависит от загрузки на работе.

[geekless]

Я не понимаю. Если makepkg и pacman предполагаются инструментами мейнтейнера, а не конечного пользователя, то о каком раздувании на клиентской машине может идти речь?

[sfs]

Основное преимущество PFS-utils перед другими существующими ПМ, в т.ч. и Pacman-ом - поддержка двух состояний пакета: "подключён" и "установлен".

В чем здесь отличие PR и PRA, если это делается одинаково: pfs-util

удалить пакет, который встроен в дистрибутив нельзя никак

А как удалить pfsmerge замешаный пакет в PR?
Если pfsextract , удалить + pfsmegre, то в PRA: makechrootpkg (pacman2pfs) список_без_удаляемого пакета
Если требуется пересобрать базовые модули - это уже следующая версия дистра

Будет утрачен минимализм (один-два запуска Pacman - и сохранёнка раздуется до огромных размеров), работа из RAM будет невозможна.

Если это критично- вместо pacman запускайте pkg2pfs или pacman2pfs - результат будет тот же

Я не услышал убедительных доводов.
Возможно что-то не понял
На словах дальше спорить бессмысленно.
Если есть энтузиасты 2го варианта - соберите PRA2. Тогда и посравниваем...

[Zay]

Попробую ещё раз объяснить: PFS - это формат пакетов, а не конструктор SquashFS модулей.
Если система собирается не из пакетов PFS, то PFS-utils в такой системе - кривой костыль.

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

Отказ от PFS как основного формата пакетов считаю большой стратегической ошибкой. Это шаг назад.

Если makepkg и pacman предполагаются инструментами мейнтейнера, а не конечного пользователя, то о каком раздувании на клиентской машине может идти речь?

В первом варианте Pacman предлагается именно как пользовательский инструмент.
Во втором - да, Pacman только для сборки PFS-пакетов.

А как удалить pfsmerge замешаный пакет в PR?
Если pfsextract , удалить + pfsmegre, то в PRA: makechrootpkg (pacman2pfs) список_без_удаляемого пакета

В PR удаление пакета возможно через GUI в несколько кликов.
Меню > Редактировать PFS > [Выбираем базовый PFS] > [Снимаем галочку с лишнего пакета] > Собрать.
А makechrootpkg это пересборка системы с нуля, закачка пакетов и т.д. - какое сравнение?

Если есть энтузиасты 2го варианта - соберите PRA2. Тогда и посравниваем...

Когда-то на нашем проекте это уже было - "лебедь, рак и щука"...