LINUX.ORG.RU

deck - пакетный менеджер для linux from scratch без гвоздей и доп зависимостей

 , ,


0

1

Пару недель назад я начал очередной подход к сборке LFS, с прицелом на дальнейшее использование в качестве основной системы. Предыдущие попытки жизни с LFS через некоторе время накрывались из-за отсутствия какого-либо управления пакетам, а все способы добавления пакетного менеджера, описаные в LFS hints, были либо слишком трудоемки, либо достаточно хрупкими и не работали через раз.

Вобщем задача была изобрести такой способ, который:

  • не нарушал воркфлоу и не требовал редактирования копипасты с LFS
  • не требовал бы установки и настройки большого количества дополнительного софта
  • можно было бы начать использовать сразу после сборки временного тулчейна

Вобщем, разрешите представить deck - hands-off package management utility for Linux From Scratch and other source based distros.

Пакеты можно ставить как обычно make && make install, утилита будет трекать новые, изменившиеся или удаленные файлы. Изменения можно примимать или откатывать, а так-же помечать к какому пакету относятся установленные файлы. Утилита статически слинкована и не требует никаких дополнительных зависимостей - можно просто бросить в путь на любой системе.


Теперь lfs не lfs, а очередная убунта?

Lavos ★★★★★
()

Идея интересная.

Не хватает возможности делать что-то подобное:

$ git clone git://git.someapp.org/someapp
$ cd someapp
$ ./configure
$ make -j9
$ deck-wrapper make install

Deleted
()
Ответ на: комментарий от Deleted
#!/usr/bin/bash
set -e
if [[ -z $(deck scan) ]]; then
	$@
	deck scan -p && deck commit
else
	echo "you have uncommited changes" && exit 1
fi

Что-то типа такого. Полноценный вариант враппера может строчек на 10 длиннее будет, или короче но на перле гг

pampa
() автор топика
Ответ на: комментарий от pampa

Не, немного не об этом. Я имел ввиду работу, похожую на checkinstall. Твой вариант, судя по коду, не отловит тот случай, когда пакет что-то ставит в /home/brokenprogram/shitstuff, например.

Deleted
()
Ответ на: комментарий от Deleted

Если директория в prune-листе то не отловит, нет. В любом другом месте отловит.

Я изначально ставил задачу, чтобы утилита работала без всякого волшебства. Просканировал, запомнил, пометил пакеты, просканировал еще раз, сравнил - показал что поменялось. Чекинсталл использует LD_PRELOAD чтобы системные вызовы перехватывать, а если coreutils статически собраны? или половина из них от бизибокса, или система на musl вместо glibc?

Свою же утилиту я могу положить в систему из загрузчика, ядра и бизибокса, и оно будет работать. Я так свою текущую систему собирал - бизибокс + deck снружи и арх в чруте.

pampa
() автор топика
Ответ на: комментарий от e1nste1n

Видел, ага. Я наверное изучил все варианты добавления пакетного менеджера в lfs, которые можно найти в интернете.

Надо будет в README добавить, чем deck отличается от утилит с LD_PRELOAD.

pampa
() автор топика

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

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

во-во, если человек не помнит все 200 000 файлов в своей системе поимённо - то он недостоин такой системы

buratino ★★★★★
()
Ответ на: комментарий от buratino

Зачем поимённо? Всё же иерархически разложено по полочкам. Конфиги в /etc, бинарники в /bin, /sbin, /usr/bin и /usr/sbin, библиотеки в /lib и /usr/lib,... и т.д.

saahriktu ★★★★★
()

Раньше пользовался достаточной популярность tripwire. Возможно стоит переписать менеджер пакетов в что-то подобное tripwire, но для отдельных директорий и очень быстрое.

anonymous_sama ★★★★★
()
Ответ на: комментарий от anonymous_sama

Корень, от которого происходит сканирование, настраивается в конфиге, Root=/path/to/directory. Какой конфиг использовать можно указать deck -c /path/to/deckrc scan

pampa
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.