4. Опакечивание своих наработок
Для арча сделано. Обновлять трудоемко (изменения проще запихать в 089*.pfs)
Пакетить еще и под дебиан не хотелось бы. Может удастся конвертер написать...
Альтернативы : собирать pacman2pfs в арче и добавлять отдельными модулями (как сейчас - 070*.pfs)
Написал скрипт
mk-dpkg распакованный модуль.pfs
Создает /var/lib/dpkg/status и пр. файлы. Т.е. создает видимость, что модуль установлен apt-ом и соответственно может быть им же удален
Это оптимальный вариант.
Не надо генерить .deb. Достаточно запустить mk-dpkg перед упаковкой модуля, например в pacman2pfs. Места много не займет и ничему не помешает
Эксперименты показали, что запариваться с подробной пропиской зависимостей, версий и конфликтов тоже смысла нет : при попытке установить ,deb с такими, же файлами как в нашем псевдопакете - получим ошибку, что эти файлы есть в нашем псевдопакете. Посде чего делаем
apt purge псевдопакет && apt install пакет и все ок.
Т.е. даже при FULL можно всегда заменить - портированную софтину на родную из деб репы
Наоборот в FULL - тоже можно сделать. Написать скрипт, который проверяет, что в системе нет пересекающихся с модулей файлов и добавляет /var/lib/dpkg/status из модуля в системный status. Не планирую такой писать. Это уже экзотика. Вряд ли в FULL нужны заморочки с портированными модулями и т.п.
Модули желательно использовать только портированные. Иначе, если не уследить и перекрыть какую-то родную деб либу - получится каша и глюки. Это на совести сборщика модуля. Никаких проверок скрипт не делает. Хотя сделать можно, но смысла не вижу
Пример псевдомодуля
evince-gtk3-p-3.26.0_64-sf08.pfs6. Самостоятельная сборка модулей из пакетов.deb
Проще будет дописать гуй для chroot2pfs
Глубже изучил chroot2pfs и понял, что гуй не нужен. Консоли и ключей достаточно. Доработал
докуТаким образом со всеми вопросами выше определился. Можно релизить. Насчет п.1. (на каком доноре) - по итогу эксплуатации определимся