оформил опции для явного управления созданием build-tree в chroot http://git.altlinux.org/people/viy/packages/?p=hasher.git;a=commit;h=7ab01b3f2a0a5ff4b8ff33e59c6bab128abba7e8
(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
