Модульный фругал и зависимые модули

[sfs]

Если модуль имеет зависимости, чего не должно быть,

Почему не должно быть зависимостей?
Предлагаете, например qt4-lib вставлять в каждую qt прогу? Большие потери на повторах
Или в базу? А есои я не юзаю прог с qt?
Лень искать, но Вы же на форуме писали что большие зависимости - это правильно

зависимости должны притягиваться автоматически и молча.

Откуда притягиваться? Из инета?
А если модуль уже на винте - вот я и предлагаю юзеру выбор

[DdShurick]

Почему не должно быть зависимостей?

Потому что должно быть: подключил - работает. Отсутствие зависимостей - самый простой вариант, иначе - "apt-get". 

Предлагаете, например qt4-lib вставлять в каждую qt прогу? Большие потери на повторах

А иначе большие потери в пользователях.

Лень искать, но Вы же на форуме писали что большие зависимости - это правильно

Да, писал, но

зависимости должны притягиваться автоматически и молча.

Откуда притягиваться? Из инета?
А если модуль уже на винте - вот я и предлагаю юзеру выбор

Опасно, запутается. У меня был напарник, в трёх проводах мог запутаться.
Если модуль на винте, есть find.

[sfs]

У меня был напарник, в трёх проводах мог запутаться.

Для таких есть pra-game и гибридная установка на флэш

Если напишите такой менеджер модулей, как описали - я только ЗА  

[DdShurick]

 Строка проверки зависимостей подключенного модуля для PRA на примере модуля skype:

Код

find /mnt/live/memory/*/skype-4.3.0.37.pfs -type f -executable -exec ldd {} \; | awk '/not/ {print $1}'| sort -u

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

Если напишите такой менеджер модулей, как описали - я только ЗА 

Он уже был написан для .pet, но из-за тогдашнего бардака в репозитории я это дело бросил.

[sfs]

Из какого репо? арч? Тогда еще надо pkgfile - вычислить по файлу модуль. Файл может оказаться в нескольких модулях. В pfs-репе нет аналога pkgfile - на этом и был затык в PR
Чтобы модуль подключился надо зафлудить сохраненку (память)
Потом модуль отключим , а хвосты в сохраненке останутся
Я много чего оптимизирую по зависимостям вплоть до перекомпиляции. Здесь в сохраненке очень скоро будет вся арчрепа
Плохая идея

[DdShurick]

Из какого репо? арч?

Чур меня! Из Альт, у них всё аккуратно разложено

Код

$ grep libQt /mnt/sda3/alexander/p7.lst
libQt4Pas5-2.5-alt0.M70P.1.i586.rpm
libQt4Pas5-devel-2.5-alt0.M70P.1.i586.rpm

Берём не devel и потрошим. Из полученных lib удаляем ненужное, остальное пакуем в sfs.

Тогда еще надо pkgfile - вычислить по файлу модуль. Файл может оказаться в нескольких модулях. В pfs-репе нет аналога pkgfile - на этом и был затык в PR
Чтобы модуль подключился надо зафлудить сохраненку (память)
Потом модуль отключим , а хвосты в сохраненке останутся
Я много чего оптимизирую по зависимостям вплоть до перекомпиляции. Здесь в сохраненке очень скоро будет вся арчрепа
Плохая идея

Вообще ничего не понял. Мы говорим на разных языках.
Здесь раньше был liblist, в котором было что и где. Мне тогда всю репу пришлось перекачать. И все - коту под хвост.

[sfs]

Вы серьезно предлагаете вкатить в арч софт из альта? Тогда у меня просто нет слов....
Или мы обсуждаем некий абстрактный дистр - тогда надо перенести из ветки ПРА

Глобальные дистронезависимые идеи, на которых я строю ПРА:
Про фругал и ПМ
Как только ПМ становится инструментом пользователя, а не сборщика модулей - фругал умер. Ставьте фул
Соответственно - RW сохраненка с софтом - это мучительный путь от фругала к фул. А это  puppy-woof (т.е. мололитный фругал с RW сохраненкой)
В моем понимании - 100% использование прелестей модульного фругала - это copy2ram +save.pfs c минимальным набором модулей. Доп. модули подкл.\откл. по необходимости

[DdShurick]

Или мы обсуждаем некий абстрактный дистр

Да

В моем понимании - 100% использование прелестей модульного фругала - это copy2ram +save.pfs c минимальным набором модулей. Доп. модули подкл.\откл. по необходимости

copy2ram преимущество сомнительное. Зато поместить пользователя не в "сферическом вакууме" а на примонтированном разделе совсем не помешает.

[sfs]

Или мы обсуждаем некий абстрактный дистр

Да

Переименовал и перенес тему

copy2ram преимущество сомнительное. Зато поместить пользователя не в "сферическом вакууме" а на примонтированном разделе совсем не помешает.

copy2ram - не преимущество, а ускорение (особенно при загрузке по сети и флэш)
Да и куда девать память на компе под вин10...
Примонтированный раздел или удаленный ресурс - еще немного времени и развитмя каналов связи и по скорости разницы не будет

[DdShurick]

Да и куда девать память на компе под вин10...

Не все так богаты

Примонтированный раздел или удаленный ресурс

Я не про это. Сейчас пользовательский каталог (/home/live в pra или /root в pr) находится в недрах системы и занимает сохранёнку. В Richy /home/live выносится на раздел, как в обычном линуксе, хотя это и не обязательно. Кроме того, одновременно можно использовать три сохранёнки: tmpfs, [234]fs и sfs. Но я отвлёкся.
 Зависимости:
 1) - Все в модуле
 2) - В модуле скрипт проверки и загрузки зависимостей. Тут варианты - либо скачивается и подключает модуль с зависимостями, который заранее изготовлен и положен в репозиторий, либо скрипт "грабит донора" и добавляет зависимости в сохранёнку.
 3) - Пользователь скачивает и подключает модуль с зависимостями сам, руководствуясь подсказками.
Лично я всегда был за первый вариант, тем более, что вы предлагаете память не экономить.

[sfs]

(/home/live в pra или /root в pr) находится в недрах системы и занимает сохранёнку. В Richy /home/live выносится на раздел, как в обычном линуксе, хотя это и не обязательно. Кроме того, одновременно можно использовать три сохранёнки: tmpfs, [234]fs и sfs. Но я отвлёкся.

Это все на любителя. Обычный симлинк - и храним что угодно где угодно
 
 Зависимости:
 1) - Все в модуле. Плохо. Огромные модули с повторами, если не портировать и не морозить репу - возможны коллизии либ
 2) Проще - рукодельный список зависимых модулей. По опыту ПРА - 2-3 максимум.

скрипт "грабит донора" и добавляет зависимости в сохранёнку

Не удобно. Сложно,  долго. Если это делать ПМ - нужна 1 либа - прилетит вагон бинарников и либ + зависимости
 3) - Пользователь скачивает и подключает модуль с зависимостями сам, руководствуясь подсказками.
Оптимально + портирование. В ПРА так и сделано

Лично я всегда был за первый вариант, тем более, что вы предлагаете память не экономить.

Я предлагаю - если памяти много - юзать copy2ram. Принцип "маленький и быстрый" считаю основным
Я бы тоже за 1 - проще всего, но нарушает принцип. Поэтому 3 без вариантов и навязчивой автоматизации средствами pfs-util в любом дистре

[DdShurick]

Обычный симлинк - и храним что угодно где угодно

Это для нас ln -s как два пальца

Поэтому 3 без вариантов и навязчивой автоматизации средствами pfs-util в любом дистре

Остаётся пожелать вам успехов в культурно-просветительской деятельности.

[sfs]

Это для нас ln -s как два пальца

/home/live выносится на раздел, как в обычном линуксе, хотя это и не обязательно. Кроме того, одновременно можно использовать три сохранёнки: tmpfs, [234]fs и sfs

- для меня не очень как 2 пальца  

Остаётся пожелать вам успехов в культурно-просветительской деятельности.

Увы никому не интересно. Все хотят готовое

[Satevis]

(/home/live в pra или /root в pr) находится в недрах системы и занимает сохранёнку. В Richy /home/live выносится на раздел, как в обычном линуксе, хотя это и не обязательно. Кроме того, одновременно можно использовать три сохранёнки: tmpfs, [234]fs и sfs. Но я отвлёкся.

Это все на любителя. Обычный симлинк - и храним что угодно где угодно

Давно интересовал этот вопрос, раз зашла речь, как реализовать /home или /home/live на отдельный раздел?

[DdShurick]

- для меня не очень как 2 пальца  

Весьма удивлён.

Давно интересовал этот вопрос, раз зашла речь, как реализовать /home или /home/live на отдельный раздел?

Это смотря в каком дистрибутиве. В PRA (porteus) - не возьмусь, в остальных - запросто.