Автоматизация действий, выполняемых при штатном обновлении пакетного менеджера?

Измени ebuild. Функция postinstall, вроде. Или можно где-то в /etc/portage вписать переопределение функции.

Измени ebuild. Функция postinstall, вроде.

Плохой совет.

Или можно где-то в /etc/portage вписать переопределение функции.

Да, в ${EPREFIX}/etc/portage/env/${CATEGORY}/${PN} (имя пакета) или ${EPREFIX}/etc/portage/env/${CATEGORY}/${PACKAGE} (пакет с версией).

Гуглить про ebuild hooks.
Например вот:
http://davydm.blogspot.com/2017/01/gentoo-adventures-running-script-after.htm...

Работает 100%, я сам пользуюсь активно для автоматического патча конфигов: Пропатчить конфиг перед его установкой в систему

В прошлый раз это всё закончилось тем, что bashrc стабильно мне портил ебилды. Это касается и примеров с генту вики.

Или же выполнять eselect opengl set nvidia после каждого обновления mesa. Раньше эта мусорная аппликуха хотя бы отображала что меса что-то там опять сломала, теперь нет. Но в то же время раньше eselect opengl не выставляла симлинки в /usr/lib64 и /usr/lib32 из-за чего ничего не работало, приходилось вручную прописывать корректные. Поскольку compat из блоба вроде как выпилили, это видимо уже не актуально.

Ужас какой. Почему в NixOS можно просто сделать services.xserver.videoDrivers = [ nvidia ], и всё работает?

Потому что кто-то позаботился о том, чтобы меса не разносила всё своей установкой?

Что-то там написано о том как автор рандомно прописывал рандомные вещи в рандомных файлах и получал рандомный результат.

Я бы хотел вполне конкретного: при появлении нового слота, удовлетворяющего условию (скажем, версия > и <) — скопировать юзерские патчи в новый слот перед установкой. После установки пакета, удовлетворяющего условию (допустим, упомянутому в package.env) выполнить определённые действия или скрипт. Желательно в песочнице и с нормальным выставлением прав на файлы, выполнять curl remotescriptfromtheinternet | sh от рута в автоматическом режиме не очень хочется.

Хотя eselect при этом должен быть вне песочницы, тут уже с этим ничего не сделать. Разве что удалять все либы месы перед их установкой вместо eselect. Вообще непонятно, зачем mesa тянут приложения, она ведь им не нужна? Некоторым нужны хидеры и проприетарные хидеры могут быть устаревшими, но я не думаю что это критично. Скорее больше вреда, если хидеры окажутся несовместимыми с нормальной реализацией.

Можно ссылки на баг-репорты или сообщения на форуме/рассылке?

Я только что попробовал применение пользовательских патчей на старых ебилдах из основного дерева, как показано тут — всё рассыпается и ничего не работает. Куда пожаловаться? В спортлото?

всё рассыпается и ничего не работает

Описание проблемы совершенно неинформативно. Есть отличная инструкция: https://segfault.kiev.ua/smart-questions-ru.html

Куда пожаловаться? В спортлото?

Ресурсы, где могут помочь, указаны на официальном сайте Gentoo: https://www.gentoo.org/support/

Оно буквально рассыпается.

/dev/fd/63: line 401: syntax error near unexpected token `fi'
/dev/fd/63: line 401: `fi #_EPATCH_ECLASS'

Любой может убедиться лично, скопировав текст по ссылке в /etc/portage/bashrc.

Создаешь файл /etc/portage/env//etc/portage/env/category/package . Пакет можно указать просто именем, или именем c версией, если хук должен применяться к указанной версии. Если нужны более сложные условия, делай if'ы в файле - см. пример ниже.

В файле создаешь функцию с именем, которая соответствует нужной стадии установки ebuild'а. Доступные стадии описаны здесь: https://devmanual.gentoo.org/ebuild-writing/functions/index.html

В файле доступны всё окружение (и переменные), которые доступны в ebuild'е. В том числе и песочница. Например, если тебе нужен файл /etc/default/grub, то обращаешься к нему "$D/etc/default/grub". Все переменные здесь: https://devmanual.gentoo.org/ebuild-writing/variables/index.html

Например, вот кусок моего скрипта, который работает только для grub:2 -второй слот (пример сложного условия по версии). Скрипт патчит файл после билда, но до установки (то есть в песочнице).

$ cat /etc/portage/env/sys-boot/grub
post_src_install()
{
  ...
  if [[ "${SLOT%%/*}" = "2" ]]; then
    ACTUAL=$( grep '^#GRUB_CMDLINE_LINUX' "$D/etc/default/grub" )
    ...
  fi
... 
}

скопировать юзерские патчи в новый слот перед установкой.

Именно просто скопировать, или наложить патчи перед компиляцией? Если наложить патчи перед компиляцией, то вообще никакого скриптинга не нужно, просто нужно патчи поместить в /etc/portage/patches/category/package

Я хочу автоматизировать вот этот процесс. Патчи для разных версий могут отличаться и требовать исправлений.

 ~ # dir -1N /etc/portage/patches/sys-kernel/
gentoo-sources:4.19.69
gentoo-sources:4.19.71
gentoo-sources:4.19.72
gentoo-sources:4.19.73
gentoo-sources:4.19.74

Возможно я также хочу автоматизировать процесс компиляции и установки ядра, потому что вызывать скрипт обновления каждые 2 дня ручками – это достаточно утомительно для меня.

Давай постепенно.

У тебя должны быть такие директории:

$ ls -1 /etc/portage/patches/sys-kernel/
gentoo-sources-4.19.69
gentoo-sources-4.19.71
gentoo-sources-4.19.72
gentoo-sources-4.19.73
gentoo-sources-4.19.74

$ emerge -v1 app-vim/minibufexpl

 * IMPORTANT: 1 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] app-vim/minibufexpl-6.5.2::gentoo  0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB


>>> Verifying ebuild manifests

>>> Emerging (1 of 1) app-vim/minibufexpl-6.5.2::gentoo
 * minibufexpl-6.5.2.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                                                                                 [ ok ]
>>> Unpacking source...
>>> Unpacking minibufexpl-6.5.2.tar.gz to /mnt/ramdisk/portage/app-vim/minibufexpl-6.5.2/work
>>> Source unpacked in /mnt/ramdisk/portage/app-vim/minibufexpl-6.5.2/work
>>> Preparing source in /mnt/ramdisk/portage/app-vim/minibufexpl-6.5.2/work/minibufexpl.vim-6.5.2 ...
 * Applying preserve_current_tab.patch ...                                                                                                                                                              [ ok ]
 * User patches applied. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>> Source prepared.
>>> Configuring source in /mnt/ramdisk/portage/app-vim/minibufexpl-6.5.2/work/minibufexpl.vim-6.5.2 ...
>>> Source configured.
>>> Compiling source in /mnt/ramdisk/portage/app-vim/minibufexpl-6.5.2/work/minibufexpl.vim-6.5.2 ...
>>> Source compiled.
...

А вот про автоматическую установку:
https://wiki.gentoo.org/wiki/Kernel/Upgrade#Automated_build_and_installation
Только там с genkernel, которую юзать настоятельно не рекомендуется. Сможешь переписать под свои нужды?

Отлично, спасибо. Я сделал вот это и одной проблемой меньше.

 ~ # cat /etc/portage/env/media-libs/mesa
post_pkg_postinst() {
  eselect opengl set nvidia
}

Потом я сделал вот это, и стало двумя проблемами меньше (нужно немного доработать на предмет получения свежей версии)

 ~ # cat /etc/portage/env/www-client/opera
post_pkg_postinst() {
  curl --tlsv1.2 -sSLO https://github.com/iteufel/nwjs-ffmpeg-prebuilt/releases/download/0.39.2/0.39.2-linux-x64.zip
  unzip 0.39.2-linux-x64.zip
  chmod -c 644 libffmpeg.so
  mv -v libffmpeg.so /usr/lib64/opera/libffmpeg.so
  rm 0.39.2-linux-x64.zip
}

Меня немного смущает, что это выполняется от рута вне песочницы, и что гитхаб (или амазон), видимо, не поддерживает --tlsv1.3 — не секурненько. Но это работает.

Похоже, что когда мне понадобятся различные действия для разных версий/слотов, мне придётся решать это в глобальном файле подобным образом? Я не могу просто указать в package.env версии, к которым применять env файл?

А вот тут не понятно. Эти каталоги нужно генерировать автоматически при их отсутствии на диске. Мне влезть в src_prepare?

Интересно. У меня в скрипте написано что-то вроде

kernelcount=$(eselect kernel list | wc -l) && ((kernelcount-=1))
eselect kernel set "${kernelcount}"
eselect kernel show
cd /usr/src/linux
cp -va /usr/src/lastconf /usr/src/linux/.config
make clean
make oldconfig
make -j5 && emerge @module-rebuild && make -j5 modules_install
eselect opengl set nvidia
cp -v /usr/src/linux/arch/x86_64/boot/bzImage /boot/EFI/boot/bootx64.efi
cp -va /usr/src/linux/.config /usr/src/lastconf

Это можно сделать лучше?

А как оно сейчас работает кстати? Видимо со старыми приложениями не очень работает? Это объясняет, почему у меня куча игрух (включая юнити) не работает нормально, или так совпало?

Потому что я вижу вот это

lrwxrwxrwx 1 root root   10 Sep 19 00:41 /usr/lib64/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root   14 Sep 19 00:41 /usr/lib64/libGL.so.1 -> libGL.so.1.2.0
-rwxr-xr-x 1 root root 471K Sep 19 00:41 /usr/lib64/libGL.so.1.2.0
lrwxrwxrwx 1 root root   11 Sep 19 00:41 /usr/lib64/libEGL.so -> libEGL.so.1
lrwxrwxrwx 1 root root   15 Sep 19 00:41 /usr/lib64/libEGL.so.1 -> libEGL.so.1.0.0
-rwxr-xr-x 1 root root 248K Sep 19 00:41 /usr/lib64/libEGL.so.1.0.0

То, что eselect opengl set nvidia (даже когда согласно этой утилите уже стоит nvidia) способно починить kwin_x11, это видимо правда. А вот вейланд у меня падает. Да и в enlightenment opengl не работает ни в иксах ни в вейланде (я его уже пропатчил чтобы он работал, всё равно не работает).

Меня немного смущает, что это выполняется от рута вне песочницы

Что ты понимаешь под песочницей? Отдельное место на диске, чтобы не повредить корень/основную файловую систему? Если так, то у emerge это есть. Сначала emerge всё делает в отдельном каталоге $PORTAGE_TMPDIR/category/package, создает слепок результата в $D (src_install) (см. https://devmanual.gentoo.org/ebuild-writing/variables/index.html), а потом мерджит этот слепок в основную ФС (pkg_install). Так что патчить ты можешь (и по-хорошему должен) не в корне после мерджа, а в $D - до мерджа.

Если тебе патчинг нужен после билда (как в моем случае), то делай это в post_src_install() - это когда полностью сформировался образ, но еще до того как образ замерджился в основную ФС. Та функция, которую ты сейчас используешь - post_pkg_postinst() - вызывается когда того как image был смерджем с основной ФС. Кстати, преимущество работы с имаджем $D состоит в том, что, если ты туда добавляешь файлы, то portage будет считать их чатью пакетов, будет показывать в equery f, будет подчищать при удалении/апдейте, будет отслеживать коллизии.

Меня немного смущает, что это выполняется от рута

owner на файлы в $PORTAGE_TMPDIR/category/package - portage:portage, так что по идее ты можешь curl, unpack и др. запускать через sudo от пользователя portage, дабы было безопасно.

Если тебе патчинг нужен до билда (то есть пропатчить исходники, до компиляции), то тебе вообще не нужен скриптинг, достаточно /etc/portage/patches/

Похоже, что когда мне понадобятся различные действия для разных версий/слотов, мне придётся решать это в глобальном файле подобным образом? Я не могу просто указать в package.env версии, к которым применять env файл?

Не знаю, работает ли способ череp env. Не удивлюсь, что если там переопределить хуки post_src_install() post_pkg_postinst() и т. п. то это будет работать.

Я пробовал только через /etc/portage/env//category/package , там у тебя доступны версия $PV $PR $PVR, слот $SLOT и вообще много чего, там можно любую логику навелосипедить. https://devmanual.gentoo.org/ebuild-writing/variables/index.html

А вот тут не понятно. Эти каталоги нужно генерировать автоматически при их отсутствии на диске. Мне влезть в src_prepare?

Не нужно их генерить. Это для ручного создания. Используй либо скриптинг, либо это.

Интересно. У меня в скрипте написано что-то вроде
Это можно сделать лучше?

У тебя буду очень активно копиться ядра. Исходники занимаю очень много места. Через некоторое у тебя закончится свободное пространство на диске. Нужно как-то подчищать старые версии исходников.

Типичная штука - нет логгинга. Вот это eselect kernel show ты никогда не увидишь, так как оно скроется за портянкой компиляции. Если ты делаешь в хуках, то используй API portage: eerror, ewarning, elog, оно хоть в логи portage будет сохраняться.

Нет error handling'а. Если у тебя компиляция упадет из-за того, что закончится место, ты будешь уполрно выполнять след. шаги.

Ядро я бы выбирал вот так: eselect kernel list | sed -n 's/.*\[\(.\)\].*/\1/p' | tail -n 1; кто знает когда и в каких ситуациях eselect kernel list выдаст пару лишних сообщений, и твой подход сломается.

Ну, и если честно, я вообще не понимаю зачем тебе часто обновлять ядра. Там ведь и поломать что-то могут.

Под песочницей я понимаю песочницу.

Собственно с post_pkg_postinst() я разобрался, вместо парсинга eselect я пишу eselect kernel set "linux-${PV}-gentoo поскольку этот этап исполняется от имени рута, всё работает. Можно ещё было включить юз symlink вместо этого.

У меня возникли проблемы с src_prepare() – он выполняется в песочнице (виртуальном окружении) от пользователя portage и не имеет доступа к системе на диске:

 * ACCESS DENIED:  mkdir:        /etc/portage/patches/sys-kernel/gentoo-sources-4.19.73
mkdir: cannot create directory ‘/etc/portage/patches/sys-kernel/gentoo-sources-4.19.73’: Permission denied
 * Failed UP phase.
 * Applying uksm-4.20.patch ...                                                                                                                                            [ ok ]
 * User patches applied.
>>> Source prepared.
 * --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
 * LOG FILE: "/var/log/sandbox/sandbox-4.log"
 * 
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: mkdir
S: deny
P: gentoo-sources-4.19.73
A: /etc/portage/patches/sys-kernel/gentoo-sources-4.19.73
R: /etc/portage/patches/sys-kernel/gentoo-sources-4.19.73
C: mkdir -p /etc/portage/patches/sys-kernel/gentoo-sources-4.19.73 
 * --------------------------------------------------------------------------------

И видимо src_prepare() – самое подходящее место, поскольку я в нём же вызываю eapply_user, но у него нет доступа за пределы песочницы. Как его получить?

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

Получается надо сделать через pkg_preinst? Но это будет не так, как я хотел. Я хотел чтобы юзерпатчи применялись, так я скопирую уже после того как пакет будет готов и патчи придётся применять на готовые файлы (первый мерж, а второго и не будет).

активно копиться ядра

rm -rf отлично работает, наверное можно пихнуть его перед kernel set

Пока я тут медитировал над процессом копирования файлов, мне вспомнилась ещё одна мыслишка. Ведь можно же удалить лишние файлы из пакета, да? Зачем мне 3 гигабайта амдшных драйверов в дереве исходников, например? Тот же linux-firmware настраивается через savedconfig (о чём не написано в хендбуке, дефолтный вариант — это гигабайты амдшных прошивок в initramfs и ядра, весящие по гигабайту), но для исходников такого нет. Очень уж долго файлы копируются. И да, у меня ссд.

Давайте, заметайте следы. Крысы. Если люди, а есть крысы, и вот это крысы. Когда крысы у руля, все адекватные люди бегут прочь.

Я попытался переместить eapply_user из src_prepare — что-то не получается

die «eapply_user (or default) must be called in src_prepare()!»

rm -rf отлично работает, наверное можно пихнуть его перед kernel set

А ничего что эти файлы были установлены emerge, и удалять их нужно только с помощью emerge --unmerge.
Ох, чувствую натворишь ты сейчас...

Да ерунда, можно пихнуть в pkg_prerm. В общем, нормально пока получается. Есть ряд условий, я пытаюсь разрулить это глобальными переменными, чтобы например не применять юзерпатчи 2 раза, да?

У меня возникли проблемы с src_prepare() – он выполняется в песочнице (виртуальном окружении) от пользователя portage и не имеет доступа к системе на диске:

А зачем тебе может понадобиться доступ к рутовой файловой системе на этапе подготовки сырцов к компиляции?

mkdir: cannot create directory ‘/etc/portage/patches/sys-kernel/gentoo-sources-4.19.73’: Permission denied

Я ж тебе два раза говорил: или скрипты, или /etc/portage/patches/ . Но не оба механизма сразу!

Тебе нужно загрузить патчи в $T и оттуда их применить.
https://devmanual.gentoo.org/ebuild-writing/variables/index.html

Я попытался переместить eapply_user из src_prepare — что-то не получается

Применять патчи из $T с помощью eapply.
Для примера найди любой ebuild содержащий eapply. Например /usr/portage/sys-devel/gnuconfig/gnuconfig-20190804.ebuild

я просто хочу ими управлять как обычными патчами, т.е. через eapply_user. Применяю в src_prepare если они уже есть и пытаюсь применить патчи от прошлого (удаляемого этим ебилдом) ядра в pkg_preinst, если их не было.

если не получится, придётся заморочиться с eapply в pkg_preinst

просто хочу ими управлять как обычными патчами, т.е. через eapply_user. Применяю в src_prepare если они уже есть и пытаюсь применить патчи от прошлого (удаляемого этим ебилдом) ядра в pkg_preinst, если их не было.

Обычный патчи управляются через eapply. Обычные патчи поставляются с ebuild'ами и лежат в каталоге /usr/portage/category/packages/files, или скачиваются в процессе установки ebuild'а.

от прошлого (удаляемого этим ебилдом) ядра

Установка одного ebuild'а не должна удалять файлы другого ebuild'а (или другой версии).

Вобщем, думаю механизмы ты понял. Но от того, что ты реализовываешь, у меня волосы на спине встают дыбом: очень со многим я не согласен. Если получишь бардак в системе, или поломаешь работоспособность после перезагрузки (ведь новое ядро так может) - тебе же разгребать. Только на Gentoo тогда не жалуйся, да?

Посему умолкаю, если будут вопросы по механизмам - пиши.

Да, спасибо. Пойду спать видимо, сейчас у меня было много проблем из-за {$var} вместо ${var}, ха. После исправления одной из первых переменных всё внезапно заработало. А пакет исходников ядра всё-таки слишком долго устанавливается, надо что-то с этим делать тоже. Я же могу удалить из пакета например файлы /usr/src/linux/drivers/gpu/drm/ и не устанавливать их? Кажется, я напортачил с путями. Если оно перестанет собираться при включении drm я особо не расстроюсь, это минус 4к файлов сразу. Я считаю, стоит поберечь ресурсы диска и время.

Удалить мусор от прошлого пакета у меня уже получилось (нужно было всего лишь вылезти из песочных каталогов, фух, у нас же есть рут в конце концов!), как и применить юзер-патчи от прошлого пакета (вроде бы), а вот удаление лишних архитектур из исходников пока нет. Меня конечно осенило, может, стоит попросить тар НЕ ИЗВЛЕКАТЬ ИХ? Как же долго он их извлекает. После извлечения видимо уже не интересно, само копирование файлов занимает около 1 секунды.