Summary: | Add more portage hooks | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Pascal Jäger <pascal.jaeger> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | gentoo, pascal.jaeger, sam, triffid.hunter |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=272988 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
portage_emergerc_functions.patch
new functions for registering hooks example emergerc |
Description
Pascal Jäger
2022-04-21 06:41:21 UTC
I could probably implement this myself similar to the existing register_success_hook function and make a PR on portages GitHub. I just wonder if there is any interest in this? I don't think I have any objections in principle. Thanks! Created attachment 774945 [details, diff]
portage_emergerc_functions.patch
put in /etc/portage/patches/sys-apps/portage-3.0.30
Created attachment 774948 [details]
new functions for registering hooks
put in /usr/lib/portage/python3.9 (or whatever python version portage uses for you)
Created attachment 774951 [details]
example emergerc
put in /etc/portage/
I cant really figure out how to use the existing MiscFunctionsProcess.py and the AbstractEbuildProcess.py. The misc-functions.sh they are using are made to be sources during an ebuild process it seems. Maybe someone with more experience with portage can have a look at that. I made this patch and ebuild-functions.sh to emulate the same behavior like the register_die_hook function, but tbh I am not very happy with that myself. This starts a new /bin/sh-process with its own environment variables. So it wont have all the goodies from emerge to do scripting with. On the other hand I don't even know if there are any important environment variables from emerge in the moment that script is sources in currently. If that is acceptable in any way, I would put the starting of that process on top of actions.py and source emergerc, then search for some more useful moments in actions.py and add hook functions for that moments. It took a while, because I forgot about this. However, here’s the PR for portage that does this: https://github.com/gentoo/portage/pull/894 It seems like you are proposing a solution without clearly defining the problem(s) you want to solve. The interface implemented in the PR only passes a single piece of data to the user-controlled script. That doesn't give much data to the script, and I'm having trouble envisioning how this would really be used in practice. It all started with the need to run timeshift-autosnap before a @world update. But I thought since there is also one hook for one special case already, instead of adding another single hook for my use case let’s solve this for many use cases at once. So, yes, only the hook that is called right before portage starts emerging the first package solves an actual problem I have. The other hooks are for users that want to automate functionality with portage. As with bashrc that could be anything. For example we are using bashrc for Sams clang14-clang15 comparison hook right now, I also use it to rebuild my initramfs in the case of a package update of one particular package. I am sure there are plenty of other uses of the bashrc hook and so there are for the emergerc hooks. I know not all of this will work for the current state of the emergerc hooks, but take a look at this thread on Reddit where users of Arch Linux present their pacman hooks, for some inspiration of what people come up with if they have the basic functionality: https://www.reddit.com/r/archlinux/comments/dsnu81/hear_ye_archers_share_your_pacman_hooks/ For more possibilities we would have to pass more information to the hooks, I also asked for suggestions in the PR I don't see why this would necessitate a solution within Portage itself, when you could just do: whatever-command && emerge -vuDN @world Or any other shell construct to run multiple commands sequentially That would run the command even when portage stops after dependency calculations because of e.g. a slot conflict or when I decide not to merge the packages in case of —ask. I admit that is not a big deal, but in this case timeshift-autosnap makes a limited amount of snapshots. If it reaches that limit it will delete the oldest snapshot when creating a new one. Before I had the hook I did this with the && approach and I often had 3 useless snapshots after dealing with some conflict and no useful snapshot from before any update at all. I could think of an other use case. User runs a headless server that is updated every week or so via cron. In case this goes wrong, the hook could be used to trigger an e-mail. Ok, then how about: emerge -pvuDN @world && snapshot && emerge -vuDN @world You'll "waste" a little bit of time maybe, but this way you'll only get snapshots when the dependency calculations are successful. Yes, I would have to do this also every time I emerge a package. I was also thinking of writing a wrapper script around emerge that does this. But I thought a integrated solution is better. I can see that this becomes way more useful when more data is passed into the hook. I was thinking about passing - the list of packages that are going to be emerged, so users can execute actions depending on that - the flags, so for example I don't want to make a snapshot when -1 is passed to emerge - if there are any news items I did that for the list of packages and the flags, but I ditched the idea with the news. Some users maybe don't want portage to check the news all the time. |