а я начну только.
C какой целью?
Sfs, необходимо взглянуть на pci id вашей карточки, чтобы добавить его в базу.
01:00.0 VGA compatible controller: NVIDIA Corporation G84M [GeForce 8600M GT] (rev a1)
Если отбросить эмоции - и тот факт, что каждый в своем дистре разбирается лучше чем в чужом - давайте все таки закроем тему "правильности пути". Может кто-что не понял в соседском методе, а там есть чему поучиться...
PRA методика сборки:Непонятные термины и сокращения - в нашей и arch wiki или спрашивайте
Цель: маленький и быстрый модульный фругал для дома. Оптимизирован для флэшек и copy2ram
В мин. конфигурации пригоден для устаревшего железа
1. porteus-initrd (русифицирован и допилен) - оптимален для модульного фругала. Приглядываюсь к uird
2. Компилим ядро по спец рецепту (определенные модули монолитно) - дает возможность не иметь в initrd модулей ядра.
3. Средствами pacman, в chroot , на базе замороженного (ARollbackM) среза Arch репы собираем минимальную базу с Х.
Можно часть (все) пакетов перекомпилить и использовать свои.
Удаляем зависимости mesa и т.п. - (перекомпиляцией cairo). Будут отдельным модулем
4. Скриптом trim удаляем маны и т.п. и отделяем dev часть. База пакетов (pkg) pacman /var/lib/pacman/local - разделяема. Каждый модуль у которого сохранена dev часть должен содержать свою часть pkg базы.
Порезанные модули не имеют pkg информации и невидимы для ПМ. При использовании
pacman * --force замещаются. Оптимально все портировать
5. Остальной софт собирается методом:
Везде оптимизируются зависимости. Все
портируется в /opt - чтобы либы не из среза арчрепы не сломали дистр в /lib . Портирование дает возможность менять срез арчрепы без переделки модулей и использовать их в др. дистрах
a. pacman2pfs - из арч репы.
б. компиляция
в. перепаровка чужих пакетов с портированием и(или) использованием либ из арчрепы
6. Свои скрипты - отдельным модулем 070 - собираются pfsmerge. Можно бы сделать pkg и собирать pacman-ом, но pfsmerge проще
В итоге имеем:
a. ПМ Совместимость с использованным срезом арчрепы при любой комбинации модулей
b. Независимость модулей софта друг от друга (если эти зависимости - только крупные типа qt mesa - не прописаны)
c. Совместимость с AUR ABS при подключении dev модуля
Мы создали свой
1й уровень . На котором неподготовленному и (или) ленивому юзеру проще, чем юзеру full+ПМ. При этом 2,3 уровень не сломаны. Т.е. возможно все (если умеешь)
Arch выбран не по политическим мотивам, а из-за ARM (морозить репу) и pacman (т.к. база пакетов без общих индексов)
На 1м уровне проще :
Вместо установки и ПМ - копирование модулей
Решение почти всех проблем перезагрузкой без сохраненки
На 2м уровне можно встроить в арч репу свою
Заплатить за "маленький и быстрый " пришлось урезанием функционала ненужного домашнему юзеру
Ну так для других применений PRA и не планировался
По изложенной методе можно собирать дистр на любом доноре, но без заморозки репы и pacman будут проблемы с работоспособностью ПМ (раздувание сохраненки обновлениями репы). Можно решать регулярным перевыпуском базы
Предлагаю разрабам MagOS написать подобное - сравним и поделимся опытом