(In reply to comment #0)
> оформил опции для явного управления созданием build-tree в chroot

А зачем понадобилось выключать заполнение /usr/src/?
Из коммита это не очевидно.

Ну, hasher у нас в альте де-факто уже больше чем
инструмент сборки, скорее платформа для дистрибутивных
решений, использующих chroot.
Используется в mkimage, gear-cronbuild, к примеру.
В связи с этим хорошо бы то что нужно для сборки
не прибивать гвоздями.
Выключать заполнение /usr/src/ может понадобиться
в каких-то случаях, чтобы не создавать лишние сущности.
Мне же сейчас нужно уметь принудительно включать заполнение /usr/src/.
Я использую для сборки на клонированном aptbox+cache (экономия памяти + увеличение быстродействия).
unchecked_initroot_cache это хорошо, но он, к сожалению, для другой задачи.

(In reply to comment #2)
> Ну, hasher у нас в альте де-факто уже больше чем
> инструмент сборки, скорее платформа для дистрибутивных
> решений, использующих chroot.
> Используется в mkimage, gear-cronbuild, к примеру.
> В связи с этим хорошо бы то что нужно для сборки
> не прибивать гвоздями.
> Выключать заполнение /usr/src/ может понадобиться
> в каких-то случаях, чтобы не создавать лишние сущности.

Допустим, хотя с тем же успехом, наверное, можно уже сейчас перенести всё в --pkg-init-list и занулить --pkg-build-list.

> Мне же сейчас нужно уметь принудительно включать заполнение /usr/src/.
> Я использую для сборки на клонированном aptbox+cache (экономия памяти +
> увеличение быстродействия).
> unchecked_initroot_cache это хорошо, но он, к сожалению, для другой задачи.

Этого аргумента я не понимаю.  Я тоже использую unchecked_initroot_cache, например, в тестовой пересборке для увеличения быстродействия -- там /usr/src/ заполняется, иначе бы ничего не работало.  Почему у вас без этой новой опции не заполняется?

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

я использую несколько другую схему,
см.
http://git.altlinux.org/people/viy/packages/?p=autorepo-scripts.git;a=tree;f=bin;h=ca2f18522b414cf9e2b695ef3c2836222a2bb9fa;hb=f9a56d30f462e33de6bccd647715225d5a3fcbd2

поднимаю в сторонке эталонный $TMP/hasher0 
содержащий эталонный aptbox && cache
с помощью 
hsh --initroot-only --number=0 && hsh-rmchroot

затем размножаю его в 32 хардлинкованных копии
hsh-clone-workdir, и восстанавливаю в каждой свой chroot
под --number=$i
c помощью hsh-mkchroot
и патченого hsh-initroot

Это другой режим работы, ведь 
unchecked_initroot_cache хочет работать со своим
чистым aptbox, а у нас aptbox после выполнения hsh-initroot.
у которого 
Я для этого патчу hsh-initroot, чтобы он не заморачивался
с провеками, а просто разворачивал готовый 
cache/chroot/chroot.cpio
и создавал build tree.

полный патченый hsh-initroot здесь, 
http://git.altlinux.org/people/viy/packages/?p=hasher.git;a=commit;h=0952ca8cb1215970e5a97a70013140f01ac268bf

но в таком виде это набор хаков, поэтому я для начала
взял опцию --no-build-tree,--create-build-tree

она там нужна, поскольку внутренняя переменная "$build_list" пуста -
если не отрывать проверки, то потому, что пакеты уже усановлены
в chroot, который мы удалили и хотим развернуть из кеша в клоне повторно
под другим псевдоползователем.
если отрывать проверки, что я делаю, то внутренняя переменная "$build_list" пуста, так как не вычисляется.
поэтому и явная опция.

(In reply to comment #4)
> Это другой режим работы, ведь 
> unchecked_initroot_cache хочет работать со своим
> чистым aptbox, а у нас aptbox после выполнения hsh-initroot.
> у которого 
уже указано, что в chroot установлен минимальный набор
из init list и build list.
этот chroot уже упакован в $chroot_archive
я хочу просто заново распаковать этот $chroot_archive
под другим псеводопользователем.
так как build tree создается отдельно от архива
с chroot, мнее его надо отдельно создать.

(In reply to comment #4)
> unchecked_initroot_cache ускоряет сборку, но не экономит
> память при параллельном запуске нескольких пересборок.

Я думаю, что unchecked_initroot_cache вполне бы вам подошёл:
запускаете hsh --init для каждого номера, после чего оставляете только одну копию cache/chroot/aptbox.tar, заменяя остальные cache/chroot/aptbox.tar ссылками на неё.

Смотрите: без использования aptbox.tar
у меня du -sh hasher1/aptbox/var/lib/apt/lists
260M    hasher1/aptbox/var/lib/apt/lists

но эти 260M не занимают места, так как это hardlinks.
ls -l hasher1/aptbox/var/lib/apt/lists
-rw-r--r-- 2 igor igor 64289424 апр  8 02:17 _var_ftp_pub_Linux_ALT_autoimports_Sisyphus_noarch_base_pkglist.autoimports
...

Как понимаю, с aptbox.tar я потеряю 8Gb=260Mb*32 на распаковке aptbox.tar,
плюс пару секунд на распаковку aptbox.tar и повторную
холостую установку пакетов из pkg-init-list, pkg-build-list
это потеря половины от первоначальной экономии в 16Gb.

Память я экономлю, так как физически в машине всего 64 Gb,
и чем меньше потребление памяти, тем больше при сборке будет
использоваться живая память, а не свопинг.

Извините, Игорь, но я решительно не понимаю, о чём вы пишите, это совершенно не стыкуется с моими данными.

Вот у меня, допустим,
unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"

Первый hsh --init (незакешированный) занимает около 24 секунд,
второй hsh --init (закешированный) занимает около 2 (двух) секунд.

Гм. Дмитрий, наверное, вы не внимательно смотрели описание.
Измерения выполнялись на машине altair на композитном репозитории:
sisyphus+autoimports/x86_64.
Такой репозиторий содержит 35.000+17.000=52.000 пакетов,
10 секунд это для него.

а у вас, как понимаю, ниспльзовался чистый sisyphus/x86_64
с 17.000 пакетов. Вы получили 2 секунды.

Для меня 10 секунд * 1.000 пакетов = 3 часа экономии для
скриптов autoimports.

Но в контексте чистого сизифа попробуйте провести
замеры на Raspberry Pi 3/4, c sisyphus/aarch64 и armh.
Думаю, там тоже будет далеко не 2 секунды экономии.

Впрочем, ALT#36531 -- это, по сути, быстрый хак,
нацеленный минимизировать вмешательство в код hasher.

Он играет вспомогательную роль для другого хака с
cp -rl закешированного hasher_workdir.

По хорошему, вместо ALT#36531 в hasher нужна
полноценная поддержка кеширования метаданных
при работе с постоянным репозиторием.

Наверно, ету тему нужно описать подробнее,
отдельным письмом.

(Ответ для viy на комментарий #9)
> Наверно, эту тему нужно описать подробнее,
> отдельным письмом.

сел разбираться, оформил в письмо
https://lists.altlinux.org/pipermail/devel/2020-September/211748.html