On Mon, Oct 24, 2022 at 10:54:17AM +0300, Anton Zhukharev wrote: > On Sun, Oct 23, 2022 at 09:52:39PM +0300, Anton Zhukharev wrote: > > On Sun, Oct 23, 2022 at 08:25:05PM +0300, Dmitry V. Levin wrote: > > > On Sun, Oct 23, 2022 at 12:39:16PM +0300, Anton Zhukharev wrote: > > > > Добрый день! > > > > > > > > Недавно столкнулся с проблемой следующего вида: > > > > > > > > [ppc64le] /usr/sbin/chroot.fakechroot: line 147: 2435617 CPU time limit exceeded env -u FAKECHROOT_BASE_ORIG FAKECHROOT_CMD_ORIG= LD_LIBRARY_PATH="$fakechroot_chroot_paths" FAKECHROOT_BASE="$fakechroot_chroot_base" "$fakechroot_chroot_chroot" "${@:1:$(($fakechroot_chroot_n - 1))}" "$fakechroot_chroot_final_newroot" "${@:$(($fakechroot_chroot_n + 1))}" > > > > 2022-Oct-22 21:18:00 :: [ppc64le] racket-main-distribution.git 8.6-alt1: remote: build failed > > > > 2022-Oct-22 21:18:00 :: [ppc64le] #100 racket-main-distribution.git 8.6-alt1: build FAILED > > > > > > > > в задании 308872. > > > > > > > > Насколько я понимаю, эта ошибка связана с разделением времени работы > > > > процессора между пользовательскими процессами (воспроизвелась только на > > > > архитектурах i586, armh и ppc64le - на x86_64 и aarch64 полёт нормальный). > > > > > > > > Есть способ обхода такого ограничения? > > > > > > Сделать так, чтобы racket перестал быть таким неуёмно прожорливым, > > > что особенно проявляется на более медленных архитектурах. > > > > > Это, конечно, не лучшее решение, но сделав установку Racket-пакетов в > > 1 поток (-j 1), пакет стал собираться (см. задание 308872). > > > > Похоже, что планировщик в установщике пакетов Racket'а работает не очень > > оптимальным образом. > > > > Что ж, решение найдено. Процесс сборки стал дольше (кстати, не сильно), > > однако мне важен результат, а не скорость. > > > > Осталось подлатать и в репозитории будет Racket ;). > > > К сожалению, я поспешил с выводами. Этот способ помог только на i586. > > Похоже, что придётся дробить (хотелось этого избежать для пакетов > входящих в main-distribution, однако придётся как-то решить проблему > взаимозависимостей). Дальше много текста, предлагается читать только тем, кому интересна идея о возвращении в репозиторий Racket (именно современного CS-варианта). -- Похоже, что раздробить всё таки легко не получится: сейчас попробую "вкраце" объяснить почему это довольно сложно в случае с Racket. Основная проблема заключается в том, что после установки каждого пакета Racket вносит данные в файл links.rktd (/usr/share/racket/links.rktd), который содержит ссылки на пакеты (по одному на строку) и ещё дополнительные данные. Это только половина беды, поскольку решается (вроде бы) выполнением команды: # raco link -i --repair Дальше - ещё веселее. Также _необходим_ файл pkgs.rktd (/usr/lib/racket/pkgs/pkgs.rktd), который необходим практически для того же для чего нужен и links.rktd (он содержит ссылки на пакеты). Он также обновляется после каждой установки/обновлении пакета. Если этот файл повредится/будет удалён/недоступен, то пакетный менеджер raco не увидит, что в системе установлены Racket-пакеты (в /usr/lib/racket/pkgs) В теории, это можно решить созданием независимого пакета, который будет содержать список со всеми пакетами из main-distribution (однако как его обновлять в дальнейшем - не совсем ясно: если кому-то понадобится установить Racket-пакет не входящий в RPM-пакет, то он должен быть (1) установлен от пользователя root, (2) он изменит файл, который принадлежит теоретическому независимому пакету (это, на мой взгляд не совсем правильно) и (3) будет конфликтовать с другими возможными пакетами с Racket-пакетами). Аналогично файлу pkgs.rktd также существуют два файла в /usr/lib[64]/racket: это launchers.rktd и mans.rktd, которые также изменяются после установки _некоторых_ пакетов из main-distribution. Они содержат запускаторы для программ, которые являются Racket-пакетами, и man-pages соответственно. Обновлять файлы pkgs.rktd, launchers.rktd и mans.rktd, возможно, получится в будущем, когда я (или не я) разберусь с кодовой базой Racket и создам свой велосипед для их актуализации. Но даже если такой велосипед будет создан, то не понятно когда его запускать: после установки каждого RPM-пакета с Racket-пакетами выглядит неоптимально, поскольку в теории может быть вызвано несколько раз, допустим при обновлении пакетов или их установки, что сильно увеличит длительность транзакции установки пакетов. Тут мне нужна помощь: существует ли возможность выполнения определенного скриптлета 1 раз в конце транзакции? Ну, допустим есть ли что-то вроде "%post --once"? // Ну или диагонально-другая идея: создать systemd-сервис, который // будет после обновления пакетов проводить операции актуализации // этих файлов. Здесь нужно ещё думать. Сейчас у меня на уме несколько идей, которые нуждаются в, как минимум, первичных обсуждениях дабы возможные пользователи Racket не испытывали дискомфорт при использовании его из нашего репозитория: 1. Оставить только RPM-пакет racket-core, а пользователей "обязать" ставить Racket-пакеты себе в домашнюю директорию. (не нравится, к тому же не работает, поскольку сейчас в репозитории Racket 8.6, а пакетный менеджер raco пытается ставить пакеты для 8.7, который ещё в стадии тестирования...) 2. Выкинуть архитектуры ppc64le и armh и собирать Racket-пакеты из main-distribution в один RPM-пакет. (ещё больше не нравится из-за отказа от некоторых платформ в нашем репозитории) 3. Попробовать ставить Racket-пакеты из main-distribution в систему, используя EEPM (использовать racket-core из репозитория и просто устанавливать Racket-пакеты в рамках локальной сборки на каждой пользовательской машине). (нравится, поскольку пакеты будут установлены в system-scope, не нужно отказываться от некоторых платформ, а процесс сборки надёжен, поскольку у него небольшие требования - разве что CPU time) 4. "Завелосипедить" свой установщик Racket-пакетов для ALT'а (я в восторге от этого варианта, но на его реализацию потребуется неопределенное количество времени). Если кому-то интересно о "возможных пользователях Racket", то они могут появиться после приобретения книги "Как проектировать программы": Фелляйзен М., Финдлер Р.Б., Флэтт М.[1], Кришнамурти Ш. Как проектировать программы / пер. с англ. А.Н. Киселева; под ред. П.Б. Иванова, А.Д. Чичинина, Ю.А. Сыровецкого, С.В. Бронникова. -М: ДМК Пресс, 2022. - 724 с.: ил. Сайт книги: http://htdp.org/2022-8-7/Book/index.html Конечно, таких пользователей может оказаться немного, однако это неплохой случай занять эту небольшую нишу в области образования. -- [1] - Флэтт М. (он же mflatt) - главный разработчик Racket (по совместительству его создатель). -- С уважением, Жухарев Антон