Стандартные пути для хранения информации

[Zay]

В разных темах неоднократно поступали предложения (от sfs и DdShurick) изменить стандартные пути хранения информации о содержимом пакетов PFS.

Сегодня список находится в файле "/etc/packages/mount/PACKNAME/pfs.files".
Было предложено переместить список в файл "/var/lib/pfs/PACKNAME.files".

При разработке спецификации PFS всё это подробно обсуждалось, но видимо забылось, поэтому кратко опишу, почему было сделано именно так, как сейчас.


Каталог "/mount" появился в пути для обеспечения возможности "установки" PFS-пакетов прямо в систему.
Сегодня это, может быть, и не самая востребованная функция, но она реализована и нормально работает.

Каталог "PACKNAME" с файлом "pfs.files" внутри сделан для хранения дополнительной информации.
Например уже сейчас там хранится информация о зависимостях пакета (если сборщик указал её).
Если убрать каталог "PACKNAME" - придётся создавать отдельные файлы типа "PACKNAME.depends".
При этом получится, что одному пакету может соответствовать несколько инф.файлов, это каша.


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

Преимущества нового варианта, с заменой стандартного пути (пункт 2):
  Более короткий путь к файлу...


Тех, кто проголосует за изменения - прошу аргументировать свою позицию в теме.

[sfs]

Я предлагал изменить только /etc/packages/ на /var/lib/pfs (как у apt pacman и пр.) и это не принципиально
pfs.depends c либами бесполезен без инструмента разрешения зависимостей
Инструмент разрешения зависимостей - это Пакетный Менеджер. Для модулей нужен ММодулей (поиск и подгрузка зависимых модулей (а не либ))
Мне ,получается, не за что сейчас проголосовать. "Против всех"  
Кто по итогу голосования будет переделыать pfs-util?

[Zay]

pfs.depends c либами бесполезен без инструмента разрешения зависимостей
Инструмент разрешения зависимостей - это Пакетный Менеджер.

Есть скрипт pfsdepends (см. документацию).
Вывод списка недостающих зависимостей на экран при подключении - тоже есть.
Это почти ПМ. Не хватает только закачки.

[sfs]

Как раз еще 1 ПМ не нужен
Нужны зависимые модули, а не либы

[DdShurick]

Каталог "/mount" появился в пути для обеспечения возможности "установки" PFS-пакетов прямо в систему.

Как говорил один мой друг - "Уму нерастяжимо!" Почему без каталога mount нет возможности?

Если убрать каталог "PACKNAME" - придётся создавать отдельные файлы типа "PACKNAME.depends".
При этом получится, что одному пакету может соответствовать несколько инф.файлов, это каша.

Для компьютера эта каша вполне съедобна. (ls pacname.*)

Преимущества сохранения существующего положения вещей

Преимущество очень большое - ничего не надо переделывать.

История вопроса. Первоначально информация об установленных пакетах хранилась в ~/.packages без подкаталогов

Код

# ls /root/.packages
buildvariables     livepackages2.txt  livepackages4.txt
livepackages.txt   livepackages3.txt  packages.txt

Это из Jeans, livepackages.txt - список пакетов в репозитории, packages.txt - список установленных пакетов.
Первым перенести ~/.packages в /etc/packages "как есть" предложил я, для обеспечения работы под пользователями, но без фанатизма, с обеспечением совместимости с Puppy.
Поэтому я за /etc/packages/ без подкаталогов.

[Pro]

Каталог "/mount" появился в пути для обеспечения возможности "установки" PFS-пакетов прямо в систему.

Как говорил один мой друг - "Уму нерастяжимо!" Почему без каталога mount нет возможности?

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

[Zay]

Нужны зависимые модули, а не либы

Не понял, какие либы? Скрипт pfsdepends выводит список необходимых ПАКЕТОВ.


Как оказалось, предложения sfs и Дяди Шурика отличаются по сути.
sfs предлагал заменить "/etc/packages/" на "/var/lib/pfs/", но сохранить структуру подкаталогов.
Дядя Шурик предлагал оставить "/etc/packages/", но убрать подкаталоги "/mount" и "/PACKNAME".
Причём оба эти варианта ведут к потере совместимости...

Почему без каталога mount нет возможности?

Собственно Pro уже ответил. Надо как-то отличать подключённые пакеты от установленных прямо в систему.
Сейчас при установке информация о пакете перемещается из "/etc/packages/mount" в "/etc/packages/install".
В Jeans и прочих Puppy не было понятия "подключаемый пакет", соответственно и подкаталог был не нужен.

Для компьютера эта каша вполне съедобна. (ls pacname.*)

Да знаю, что съедобна. Но в чём принципиальное преимущество? Лишний каталог занимает место в файловой системе?
Сейчас структура логична и проста: Один пакет - один подкаталог. Даже без спец. инструментов понятно, что к чему.
А что нам даст замена "шила на мыло", кроме потери обратной совместимости?

[DdShurick]

 Саша, ты должен помнить, это было решено в get_pet.

Надо как-то отличать подключённые пакеты от установленных прямо в систему.

Это элементарно, у нас же есть слои. Информация об установленных пакетах всегда будет в сохранёнке.

Код

find /initrd -name *.files | egrep 'pup_rw|pup_ro0/|pup_ro1/'

А что нам даст замена "шила на мыло", кроме потери обратной совместимости?

Ничего.

[Zay]

Это элементарно, у нас же есть слои. Информация об установленных пакетах всегда будет в сохранёнке.

Код

find /initrd -name *.files | egrep 'pup_rw|pup_ro0/|pup_ro1/'

И как тут понять, какой пакет в данный момент подключен, а какой установлен (и его можно удалить) - ?

А что нам даст замена "шила на мыло", кроме потери обратной совместимости?

Ничего.

Ну и о чём тогда дискуссия? Получается что оставить как есть - наилучшее решение. С этим все согласны?

[DdShurick]

И как тут понять

Обыкновенно, головой. Файлов подключенного пакета не может быть в сохранёнке.

наилучшее решение.

Но некрасивое.

[Zay]

Обыкновенно, головой. Файлов подключенного пакета не может быть в сохранёнке.

Причем тут голова, откуда скрипт удаления пакетов получит информацию?
Или может find-ом искать по слоям aufs-а, где файлы из пакета? Кошмар...

Кроме того, при разработке спецификации PFS универсальность была (и остаётся) одной из главных задач.
Поэтому вся информация о пакетах должна быть доступна прямо из корневой ФС, без раскопок в слоях.

наилучшее решение

Но некрасивое.

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

[DdShurick]

Причем тут голова

При том, что ей обычно думают, а не стучат об стену.

откуда скрипт удаления пакетов получит информацию?

Из $pacname.files

Или может find-ом искать по слоям aufs-а, где файлы из пакета? Кошмар...

Никакого кошмара, find для этого и создан.

Поэтому вся информация о пакетах должна быть доступна прямо из корневой ФС, без раскопок в слоях.

С точки зрения безопасности, доступность это плохо.

[Zay]

Из $pacname.files

"Вот этот конкретный" пакет '$pacname' - подключен или установлен сейчас?

Никакого кошмара, find для этого и создан.

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

С точки зрения безопасности, доступность это плохо.

Чем плохо? Сломать же ничего нельзя, доступна только информация.

[DdShurick]

"Вот этот конкретный" пакет '$pacname' - подключен или установлен сейчас?

Код

# pacname=openssl-1.0.2a
# find /initrd/pup_r[ow][!2-9] -type f -name ${pacname}\.files
/initrd/pup_ro1/var/lib/pfs/openssl-1.0.2a.files

Исходя из ro1, вывод - установлен в save.sfs. "Это элементарно, Ватсон."

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

Ну что тут сказать, банальное "учите матчасть"

[Zay]

Ну что тут сказать, банальное "учите матчасть"

"Учить матчасть" никогда не вредно.
Здесь дело не в этом, а в том что вместо одной строки кода придётся писать N-ное количество.

Код

ls /etc/packages/install 

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