Как сделать задачу <X> и при этом не засрать систему в хлам?

Опакетить? А вообще ж оставишь сорсы сделаешь make uninstall потом.

Контейнер?

Делайте себе chroot и там ставьте/удаляйте любые пакеты как хочется.

chroot, контейнеры.

chroot или контейнеры.

debootstrap нужной версии (может более старого) дебиана — туда chroot и срешь там как хочешь. В конце просто удалишь эту директорию.

/thread я думаю

О, а вот chroot выглядит интересно. Дело я с ним никогда не имел, но правильно ли я понимаю, что это система внутри системы (а-ля виртуалка), только с производительностью почти равной нативу?

make uninstall потом

только надо убедиться, что цель uninstall прописана в Makefile проекта.

Вы не совсем поняли. Приходится сильно раскочегарить хост систему чтобы подготовить её как пригодный Build Environment. Другое дело что откатить потом все изменения очень сложно и потому я ищу альтернативу вируалке но с годной производительностью.

docker

в chroot нет никакой потери производительности — вообще никакой — это нативная система с измененным / (rootfs)

Вот оно как. Спасибо, пойду копать в его сторону.

Откуси от харда десяток гигов и собирай там.

У меня SSD и откусывать и без того маленькую партицию не очень хорошо. Да и пакеты для сборки то я в систему основную тяну, это мне никак не поможет.

Вопрос вот в чем: Как решать такие задачи и при этом не засирать хост систему?

Удваиваю контейнеры. Может для сборки ядра и chroot хватит, но вообще штука очень удобная.

А что конкретно из контейнеров посоветуете? Я в этом вопросе мало что понимаю: Хост Debian, если это важно.

pbuilder /thread

lxc

pbuilder. Чистое chroot-окружение с системой

Да и пакеты для сборки то я в систему основную тяну

Зачем в основную? Всё в chroot. https://docs.oseems.com/general/operatingsystem/debian/build-chroot-environment , разве что добавить добавить ″--variant=minbase″ к опциям ″debootstrap″. Можно запустить sshd в chroot на другом порту, можно заходить через chroot. И туда сразу ставить нужные версии пакетов, а из основной системы посносить всё лишнее, чтобы ssd не забивать под завязку.

Вместо chroot в некоторых случаях удобнё использовать overlayfs. Вы можете смонтировать overlayfs поверх вашей уже существующей фс, а все изменения, сделанные внутри overlayfs, будут складываться в отдельную директорию, которую вы сможете потом с лёгкостью удалить.

Overlayfs поверх корня — очень просто. Если сделаешь upperdir в tmpfs, то после ребута сотрутся все изменения, естественно. Удобно сделать upperdir на диске и подключать по мере надобности.

А что конкретно из контейнеров посоветуете?
Хост Debian

Если дебиан 8 и выше, то, разумеется, systemd-nspawn :) Не, без шуток, я именно для сборки и именно на дебиане в качестве хост-системы эти контейнеры использую, просто и удобно. В минимальном случае делаешь что-то типа

debootstrap --arch=amd64 stable ~/debian-tree/
systemd-nspawn -bD ~/debian-tree/

и ставишь что хочешь и собираешь себе всё, что угодно.

Когда-то пилил вот такой костыль: http://welinux.ru/post/1801/ Не знаю, будет оно работать сейчас или нет, ибо контейнеры, виртуалки и chroot.

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

Виртуалка не очень подходит ибо производительность сливается очень сильно

Просто вы не умеете это готовить. Оверхэд какого-то ксена просто минимальный.

Я очень зеленый в этой теме

Зеленый, как слоник? :)

Вопрос вот в чем: Как решать такие задачи и при этом не засирать хост систему?

chroot с debootstap же. А зачем такие извращения вообще? Что за ведро такое, что его голыми руками не собрать?

Просто вы не умеете это готовить.

Если ксен паравиртуальный, т.к. судя по всему, у этого нищеброда ещё и проц без виртуализации.

Под ведром я имел ввиду Android, а не ядро, если ты об этом.

<slowpoke>
У тебя есть контакты для связи? Дурка, почта? У меня просто жаббера нет, а другого у тебя в профиле не указано)
</slowpoke>

LXC, если ядро древнее то старый добрый chroot.

Тут товарищь выше просто советует systemd-nspawn, коли уж он у меня есть, может проще использовать его.

Слишком унылый и тупой тролль.
http://ark.intel.com/products/75047/Intel-Core-i5-4670-Processor-6M-Cache-up-...

Самокритично, бро ;)

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

lxc-create -n base -t debian
lxc-clone base build1
lxc-clone base build2
lxc-start -n build1
lxc-attach -n build1
и тд

У тебя есть контакты для связи?

Есть, джаббер.

У меня просто жаббера нет

ССЗБ :)

lxc-create -n base -t debian

Ну да, чуть короче, чем я выше привёл для systemd, но не критично

lxc-clone base build1

machinectl clone base build1

lxc-start -n build1

machinectl start build1

lxc-attach -n build1

machinectl login build1
systemd-run -M build1 command

и т.д. Похожие средства с похожим функционалом. Для не-systemd хоста я бы сам выбрал lxc, но для systemd-хоста удобнее родные средства, они есть из коробки и имеют некоторые дополнительные возможности.

machinectl это всего лишь очередная надстройка над liblxc, и не более.

machinectl это всего лишь очередная надстройка над liblxc, и не более.

Мужикам, надеюсь, сообщили?

Думаю всем пофиг.

Попробовал сегодня, остался один вопрос. Вот создал я директорию, натравил на нее debootstrap, потом сделал systemd-nspawn /path/debootstrap/dir
У меня появился chroot shell, я в нем нашаманил, сделал что надо, и теперь чтобы вылезти оттуда достаточно написать logout? Просто в арч вики описано про контроль контейнеров, но у меня machinectl list выводит пустой список, дескать ничего нет. Может я где накосячил или это норма?

А, родил. Я делал systemd-nspawn -D, что просто спавнило мне shell, чтобы контролить через machinectl нужно было запускать этот бубен с -b. Но в целом, собрал я там AOSP, хост чистенький, бл*дское волшебство, гдеж я раньше то был.

О, а вот chroot выглядит интересно. Дело я с ним никогда не имел, но правильно ли я понимаю, что это система внутри системы (а-ля виртуалка), только с производительностью почти равной нативу?

Ядро то же. Набор файлов другой. Производительность не почти равна, а идентична. Легко делать бэкапы, можно инкрементальные. Хорошая идея, в общем.

Кстати, если уж речь зашла, а есть какой-нибудь удобный способ сделать всё это без дублирования всех файлов на диске? Скажем всё, что в /usr, можно использовать из родительской системы, там файлы не меняются.

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

С одной стороны я с тобой согласен. По началу я вообщше думал, что системные файлы в контейнере - это просто симлинки на хост, но, в контексте с дебианом например через debootstrap можно развернуть любую ветку (stable/unstable/testing) и тогда такой подход не подойдет, версии ведь разные.