Инструмент закачки пакетов из сети

[Zay]

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

1. Выводить список пакетов, имеющихся в репозитории.*
2. Обеспечить возможность текстового поиска по названиям пакетов в репозитории.
3. Скачивать указанный пакет с зависимостями, и объединять их в один файл .pfs.

Принцип организации закачки пакета с зависимостями может быть таким:
Качаем пакет, получаем список его зависимостей с помощью вызова pfsdepends, скачиваем зависимости по списку, рекурсивно проверяем их зависимости, пока не будут удовлетворены все, затем объединяем пакеты с помощью pfsmerge.


* С учётом того, что файлы .pfs могут содержать внутри пакеты с другими названиями, при наполнении репозитория необходимо правило:
Один файл .pfs на каждый пакет, название файла - [PACKNAME].pfs.

[DdShurick]

 Опять какой-то rpm-щиной запахло.
Модуль, находящийся в открытом репозитории не должен иметь зависимостей кроме особо крупных.

1. Выводить список пакетов, имеющихся в репозитории.

Это уже есть. DISTRO_REPO берём из DISTRO_SPECS

Код

. /etc/DISTRO_SPECS
curl $DISTRO_REPO | awk -F [\<\>] '!/Index/ {print $3 $5}' | grep ".." > /tmp/repolist

Далее думаем, в чём открыть /tmp/repolist, чтобы

2. Обеспечить возможность текстового поиска по названиям пакетов в репозитории.

А вот это

3. Скачивать указанный пакет с зависимостями, и объединять их в один файл .pfs.

уже для разрабов. Качаем, конструируем....

С учётом того, что файлы .pfs могут содержать внутри пакеты с другими названиями, при наполнении репозитория необходимо правило:
Один файл .pfs на каждый пакет, название файла - [PACKNAME].pfs.

Согласен, но добавлю - закрытого репозитория.
Может быть модули имеет смысл делать .xzm?

[sfs]

Давайте определимся с терминологией
Пакет - это то, чем оперирует пакетный менеджер
pfs , sfs - это модули. Они подключаются, а не устанавливаются
Функционал установки в pfs есть, но не востребован
Если даже заморачиваться from scratch - проще взять готовый ПМ и компилить свою репу его формата
Модуль должен быть функционально полным (для конкретного дистра) типа qt perl python. Зависимости модулей не должны быть до каждой либы.
Сами модули делать руками (PR) или переконвертацией чужих пакетов (для pacman - PRA; deb - Debiandog; rpm - MagOS). В этом и будет универсальность

Предлагаю такой подход:
1. Не изобретать велосипед (новый ПМ)
2. Заложить только функционал ручной прописки зависимостей модулей

По итогу :
1,2 - да
3. Ничего объединять не нужно если зависимости разрешаются на уровне больших модулей. Пример: vlc.pfs зависит от ffmpeg.pfs и qt4-lib.pfs . Если кому-то надо объединить - pfsmerge (для этого все есть зачем что-то еще)

Все написано по итогу уже большого опыта PRA, реализовано именно в таком виде в
http://wiki.puppyrus.org/soft/sfs-get (код надо чистить - складывался исторически)
и есть альтернатива
http://forum.puppyrus.org/index.php/topic,16438.0.html

[sfs]

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

Полностью поддерживаю

Согласен, но добавлю - закрытого репозитория.
Может быть модули имеет смысл делать .xzm?

От кого и зачем закрытого? Маленькие модули от юзеров.... Оптимально трехуровневость . Для PR вместо pacman - 2й уровень - это сборка пакетов 1го уровня (самодостаточных)
В чем смысл .xzm? Может - детектить формат и класть на расщирение (любое)

[Zay]

pfs - это модули

Нет! Это как раз пакеты, которые отличаются от deb / pet / rpm возможностью подключения, и возможностью объединения нескольких пакетов в один файл.

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

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

Если даже заморачиваться from scratch - проще взять готовый ПМ и компилить свою репу его формата

Вот с этим не согласен!
Ещё не хватало, тащить чужие неполноценные ПМ, вместо того чтобы немного доработать свой, уже имеющийся, с уникальным и востребованным функционалом.

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

[sfs]

1. Я не считаю, что мы готовы написать ПМ уровня известных. Сейчас pfs-util очень далеко от ПМ. Делать это надо не на sh
2. Нет больше желающих компилить все из исходников. Даже если сделать 1 - ему не с чем будет работать
3. В чем универсальность pfs-util, если он станет ПМ

Про модули давно пора забыть, они своё отжили. Многопакетные файлы PFS превосходят их по всем параметрам.

Чем в этом контексте модуль отличается от Многопакетные файлы PFS?

[Zay]

1. Я не считаю, что мы готовы написать ПМ уровня известных. Сейчас pfs-util очень далеко lj ПМ.

Чего не хватает PFS-utils сегодня как ПМ, кроме закачки пакетов?

Делать это надо не на sh

Проблем с SH не вижу. Скорость после оптимизации хорошая. + Независимость от компиляторов, лёгкость доработки.

2. Нет больше желающих компилить все из исходников.

Как я понял из обсуждений в соседнем разделе - желающие есть. Многие не хотят зависеть от чужого репозитория.

3. В чем универсальность pfs-util, если он станет ПМ

Универсальность в использовании возможностей формата - подключение (самое ценное!) и объединение/разделение.


По теме шапки - сценарий работы пользователя может быть таким:

Допустим пользователю нужен Firefox. Он запускает соотв. утилиту, набирает там "Firefox" и ждёт.
Утилита выполняет инструкцию из шапки темы, и выдаёт пользователю на блюдечке многопакетный файл Firefox.pfs, внутри которого будут пакеты "firefox", "flashplayer" и прочие необходимые, но отсутствующие в системе.

При желании, пользователь или разработчик может выложить на FTP или файлообменник уже готовый Firefox.pfs для тех, кто по какой-то причине не хочет использовать ПМ.

[sfs]

Чего не хватает PFS-utils сегодня как ПМ, кроме закачки пакетов?

Наберите apt-get --help или pacman --help и сравните
Как минимум не хватает пакетов.pfs. Теоретически желающие есть - практически пакетов нет и своя полноценная репа - нам не по силам. Да и чем она будет лучше любой другой?
Все ПМ на С пишут. Мы самые умные?

Универсальность в использовании возможностей формата - подключение (самое ценное!) и объединение/разделение.

Да - и простота. Не надо усложнять до ПМ. Надо упрощать до функциональных модулей
Firefox - должен быть в репе собранный опытным разрабом

[Zay]

Чего конкретно не хватает PFS-utils как ПМ? Какого функционала?

Как минимум не хватает пакетов.pfs.

Вот это чем не устраивает?
http://mirror.yandex.ru/puppyrus/puppyrus/repository/
Желающие компилировать есть, см. соседний раздел.

Все ПМ на С пишут. Мы самые умные?

Хотя бы и так. Puppy, в своё время, тоже был передовой системой. Тогда все дистрибутивы требовали установки на отдельный раздел. Так что пусть мы будем "самые умные".

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

Это не простота, а ущербность. При наличии PFS-utils никакие другие типы пакетов или ПМ в системе не нужны. Зачем плодить сущности?

[sfs]

Как в нашей репе поставить пакет со всеми зависимостями? pacman -Sy ; apt-get install
Как обновить весь дистр? pacman -Syu ; apt-get dist-upgrade

Я воспринимаю pfs-util только как подключалку-объединялку
Для маленьких самодельных пакетов (модуль 070 в PRA) в итоге перешел с pacman на pfs-util - так проще и удобнее
Качалку и рукописные зависимости прикрутил сам в sfs-get. Больше ничего не нужно. Нужно упрощать и совершенствовать этот функционал
Снимите розовые очки. Нет у нас сил делать свою репу. Не тратьте время на ПМ. Чем наша репа должна быть лучше других? Домашнему юзеру надо просто и понятно. Надо работать в этом направлении

[Zay]

Как в нашей репе поставить пакет со всеми зависимостями? pacman -Sy ; apt-get install

Это как раз в шапке темы описано.

Как обновить весь дистр? pacman -Syu ; apt-get dist-upgrade

Для Frugal дистрибутива вообще не актуально.

Чего ещё не хватает?

Я воспринимаю pfs-util только как подключалку-объединялку

И напрасно. Возможностей у PFS значительно больше.
Хотя в контексте использования "как в PRA" этот функционал не востребован. Но сейчас идет речь не о PRA.

Чем наша репа должна быть лучше других?

Тем же, чем наш дистрибутив лучше других. Почему бы тогда не использовать MagOS / Porteus / Arch / etc. ?

Тема опять съезжает в дискуссию "Свой репозиторий vs. Чужой репозиторий".
PFS является наилучшим форматом пакетов для собственного репозитория. PFS-utils - оригинальный ПМ для таких пакетов.
Собирать свой репозиторий из пакетов других типов - не рационально. У формата PFS значительные преимущества. ИМХО.

[sfs]

Давайте уже делать скачку и зависимости
Чтобы все остались довольны придется делать зависимости на 2х уровнях: либ и модулей
Что берем за основу? Или пишем с нуля? Кто пишет - в какие сроки?
Если sfs-get - жду отчетов что с ним не так

[Zay]

Давайте уже делать скачку и зависимости

Зависимости на уровне пакетов есть и работают. Зачем ещё один уровень?
По поводу скачки - набросок ТЗ в шапке темы. Что брать за основу - не знаю...

[sfs]

Предлагаю и объединять их в один файл .pfs.
pfsdepend сейчас проверю

[Zay]

Предлагаю и объединять их в один файл .pfs.

По поводу объединения - можно спросить пользователя (сделать чекбокс в GUI).