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

Автор Тема: Разруливание зависимостей в pfs-util  (Прочитано 16167 раз)

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

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33953
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:Разруливание зависимостей в pfs-util
« Ответ #15 : 26 Ноябрь 2013, 09:51:07 »
Проблема в том , что мы с Вами пытаемся решить разные задачи:
Вы пытаетесь написать ПМ для дистра в котором его нет, а я пытаюсь навести порядок в модулях (убрать повторы)
Да, Вам надо по полной заморачиваться с ldd (кстати посмотрите dep-find в PRA и depfinder в слакваре)
Мне достаточно собрать более маленькими кусками , прописать руками и поудобнее автоподключить.

Подход "Вместо|вместе||под" не всегда оправдан. Может получиться "неподочто"
В итоге каждый рвется изобрести свой велосипед, а то как я уже сделал в pra1311d вообще никому не интересно.
...вот такая коллективная работа... :'(
Уже неделю трем. Продвижения 0. Я уже склоняюсь - пусть каждый сдалает как видит - итоги сравнить
« Последнее редактирование: 26 Ноябрь 2013, 09:53:36 от sfs »

Оффлайн DdShurick

  • Это Риччи
  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 8633
  • Репутация: +187/-2
  • Старый чайник
Re:Разруливание зависимостей в pfs-util
« Ответ #16 : 26 Ноябрь 2013, 10:32:54 »
кстати посмотрите dep-find в PRA
Посмотрел, тот же ldd, только "обвешанный кружевами".
Мне достаточно собрать более маленькими кусками , прописать руками и поудобнее автоподключить.
Как в rpm-based? Стоит ли полученная экономия затраченных трудов и усложнения?
Подход "Вместо|вместе||под" не всегда оправдан. Может получиться "неподочто"
Не только. Может получиться "нуваснаф" :)
В итоге каждый рвется изобрести свой велосипед, а то как я уже сделал в pra1311d вообще никому не интересно.
...вот такая коллективная работа... :'(
Уже неделю трем. Продвижения 0. Я уже склоняюсь - пусть каждый сдалает как видит - итоги сравнить
Естественно, здесь же одни конструкторы. "Чукча не читатель, чукча сам писатель"
Моноблок Lenovo IdeaCentre c200 (Intel Atom D525, Intel GMA 3150, 2 Gb RAM) Richy64
Nettop Acer Aspire Revo R3610 (Atom N330, nVidia GeForce 9400, 3 Gb RAM) Richy64

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33953
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:Разруливание зависимостей в pfs-util
« Ответ #17 : 26 Ноябрь 2013, 10:54:05 »
dep-find - да так и есть. Надо бы его причесать. Если будете подобное писать - держите в курсе
depfinder - хитрый какой-то. Есть либа на C. В PRA иногда виснет. Недоразобрался

В плане зависимостей модулей - я хочу выделить питон qt mesa gtk3 и прочие крупняки. Не мельче

Про писателей - я уже давно столько букв не писал. И все впустую. Надо форкать. Мне нужен рабочий инструмент, а не икона и не памятник. Сейчас допилю sfs-get и если  конструктив не появится ...  :'(
« Последнее редактирование: 26 Ноябрь 2013, 10:55:48 от sfs »

Оффлайн DdShurick

  • Это Риччи
  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 8633
  • Репутация: +187/-2
  • Старый чайник
Re:Разруливание зависимостей в pfs-util
« Ответ #18 : 26 Ноябрь 2013, 13:59:42 »
В плане зависимостей модулей - я хочу выделить питон qt mesa gtk3 и прочие крупняки. Не мельче
Правильной дорогой идёте, я тоже примерно так планировал. Если бы репа не подкачала, не пришлось бы начинать всё сначала.
Моноблок Lenovo IdeaCentre c200 (Intel Atom D525, Intel GMA 3150, 2 Gb RAM) Richy64
Nettop Acer Aspire Revo R3610 (Atom N330, nVidia GeForce 9400, 3 Gb RAM) Richy64

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33953
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:Разруливание зависимостей в pfs-util
« Ответ #19 : 26 Ноябрь 2013, 14:23:10 »
Если бы репа не подкачала, не пришлось бы начинать всё сначала.
:D Не зря неделю в литературе упражнялись. Уже и стихами могём

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Re:Разруливание зависимостей в pfs-util
« Ответ #20 : 06 Декабрь 2013, 16:57:54 »
где-нибудь есть собранное вместе описание того, что за функционал хочется получить и как им управлять.

я читая форум запутался.

Кто-нибудь может такое собрать в кучу, если еще нет такого?
Наверняка кто-то охватывает в своем уме всю идею?

Мне хотелось бы подключиться и продолжить сотрудничество. Особенно в части унификации утилит управления сжатыми образами и их подключение в корневую фс.

После формулирования идей, стоит сделать общий репозиторий кода в одном месте, например на github.
Без этого не сдвинемся в сторону.

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

Давайте попробуем?

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33953
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:Разруливание зависимостей в pfs-util
« Ответ #21 : 06 Декабрь 2013, 17:09:29 »
Кто-нибудь может такое собрать в кучу, если еще нет такого?
1. Подключение-откл.
2. склейка-расклейка (rsynk ?)
3. установка-удаление - не уверен что надо вообще там где есть ПМ
4. рукописные зависимости для крупных модулей
5. поиск в ftp\http и url базах (как в sfs-get) и скачка с зависимостями. www: curl -l ; url: wget файл со списком url - парсить, качать , подключать. Здесь gui необходим - можно вдохновиться sfs-get

Желательно все на консольных утилитах + gui к ним на gtkdialog \ yad (налажена связь с автором). Желательно использование стандарта нотификации типа моего ntf с поддержкой notify-send (для дистронезависимости)
Желательно автопонимание sfs pfs и прочие squashfs и дистронезависимость

В варианте pfs-util + sfs-get все это есть и работает. Но уровень не "промышленный". Много исторических наслоений и костылей
« Последнее редактирование: 06 Декабрь 2013, 17:13:19 от sfs »

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Re:Разруливание зависимостей в pfs-util
« Ответ #22 : 06 Декабрь 2013, 17:18:36 »
Давайте попробуем тогда внести изменения в pfs-util через общий репозиторий, чтобы с ним было удобно работать через систему версионности?

В коде должно быть по возможности вынесено дистрозависимое в конфигурационные переменные, чтобы например можно было легко написать:
PACKET_PREFIX=xzm или PACKET_PREFIX=pfs и т.д

Необходима локализация (gettext ???)

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33953
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:Разруливание зависимостей в pfs-util
« Ответ #23 : 06 Декабрь 2013, 17:24:25 »
Давайте попробуем тогда внести изменения в pfs-util через общий репозиторий, чтобы с ним было удобно работать через систему версионности?
Тогда уж давайте сначала доформулируем идею, средства, утвердим спецификации и поймем кто и чем готов заниматься и в какие сроки
Наши авторы этих утилит не профессиональные программисты. Систему версионности могут не осилить или придется учить
gettext не помешает. Хотя бы на перспективу, но писать лучше на русском
« Последнее редактирование: 06 Декабрь 2013, 17:26:00 от sfs »

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Re:Разруливание зависимостей в pfs-util
« Ответ #24 : 06 Декабрь 2013, 17:57:18 »
Вот так я вижу функционал подобного рода утилит:

1. Утилита позволяющая собирать модули (мы привыкли в своей терминологии так называть squashfs образы) на основе родных утилит ПМ дистрибутивов: yum, apt-get, urpmi, pacman и т.д. со всеми зависимостями, которые необходимо доустановить до определенного слоя aufs. У нас берется слой базовой поставки дистрибутива, но должна быть гибкость регулирования этим процессом выбора слоя.
2. Утилита позволяющая собирать модули из произвольной директории и именующая полученные модули в соответствии с принятой системой именования: NN-название-(доп. инфо: версия, источник и т.д.)-версия_дистрибутива-ник_сборщика-дата.xzm
3. Утилита позволяющая подключать и отключать НА ЛЕТУ модули в систему в определенный слой aufs (достаточно думаю - вначало или конец)
4. Утилита строящая общие зависимости между несколькими модулями (для начала - двух) и формирующая модуль с общими библиотеками и файлами.
5. Утилита работающая с сетевыми репозиториями модулей (подключение и отключение) с последующей возможностью подключения/отключения/скачивания модулей
6. Утилита обеспечивающая управление сохранениями (утилита делающая слепок системы, замораживающая состояние и разворачивающая бранчи для изменений в определенном слое aufs - это мечта, но пока она в полном объеме на текущих версиях aufs не реализуема)
7. продолжение следует

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33953
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:Разруливание зависимостей в pfs-util
« Ответ #25 : 06 Декабрь 2013, 18:12:35 »
1,6 - пускай каждый дистр делает под свое иначе не получится дистронезависимости
2. надо бы унифицировать расширение или еще лучше поддерживать список расширений с проверкой на пригодность к разборке
3. Надо luram (ниже, выше, в память) тут нет ничего сложного
4. Может для начала (а может и вообще) ограничиться рукописным списком зависимых модулей, может с версией. Иначе просто не будет и зачем "отнимать хлеб" у ПМ
5. и обновление списков реп
7. да вроде достаточно

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Re:Разруливание зависимостей в pfs-util
« Ответ #26 : 06 Декабрь 2013, 18:34:49 »
4. имеет смысл вообще только если заморачиваться размером дистрибутива. Мне это не критично, поэтому зависимости между модулями на практике никогда не являются востребованными при той организации дистрибутива (разбивка на модули), что выбрана у нас: ядро, базовая часть, утилиты, сетевые утилиты, qt, gtk, x, lxde, gnome, kde, и т.д.

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

Из практики не возникало необходимости знать зависимости между модулями. Большая часть регулируется на этапе сборки через последовательную нумерацию: NN-.... Итогом все модули иерархически зависимы только от нижележащих модулей по индексу и этого достаточно. А Если подключать произвольный модуль еще и в нужный слой, то проблема зависимостей вообще будет решена при условии незаморачивания размером.

А Вот 4 пункт нужен как раз для процедуры когда можно пройтись по модулям и выделить правильную иерархию с сокращением избыточности одних и тех же компонент в лепестках ромашки.

1,6 нужно постараться сделать через префиксы названий ПМ и параметров для них вначале скрипта, но сам скрипт более не должен быть завязан на большой дистрибутив лежащий в основе.

2 лучше унифицировать расширение, но дать возможность в переменных их менять.

5. обновление списков реп - да

7. Еще нужны утилиты для сетевых наворотов и работы в бездисковых вариантах, а также обновления и синхронизация через репозитории и другие минимальные возможности собрать модульные слои по сети для гибкого использования в инфраструктурных решениях крупных организаций. Но это отдельная история :)

Оффлайн Zay

  • Почетный участник
  • Ветеран
  • *
  • Сообщений: 1536
  • Репутация: +25/-0
Re:Разруливание зависимостей в pfs-util
« Ответ #27 : 06 Декабрь 2013, 19:54:03 »
Спецификация PFS (техническая) есть в документации - http://wiki.puppyrus.org/puppyrus/pr218/pfs
Там же описано большинство возможностей существующих утилит.

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

Локализация полезна только для GUI-скриптов, все консольные скрипты PFS-utils на английском 100%.

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

Расширение (pfs \ xzm) в переменной - а зачем это?
Скрипты сборки/разборки используют списки в /etc/packages, расширение .pfs предполагает наличие этих списков, другие расширения - нет.
А скрипты подключения (тот же pfsload) полностью универсальны, можно использовать абсолютно любые расширения, тип ФС определяется по содержанию файла.

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