xbps hooks

[Duncaen]

Hooks should all run at once, before all packages are extracted and after all packages are extracted,
to avoid running programs while only some packages are extracted which might break hooks.

Targets are either pre/post, we probably also need to have ways to distinguish between install/update/remove.

Hooks should match package names, matching file or nothing (for snapshots etc).

Hooks should be able to collapse so that we don't have to update the font-config cache N-times as its currently happening with triggers.

Resources:

1. https://www.archlinux.org/pacman/alpm-hooks.5.html

[Chocimier]

Triggers are almost there. They need change of targets mode to, say, events mode that takes {before,after}-transaction argument and prints events on which it should be run, one per line, eg. path:usr/share, {package,​installed,​uninstalled,​updated}:pkgpattern. Matched events will be passed as arguments of run mode.

Only hooks installed on filesystem at the time will be run, ie. no after- of packages removed in transaction, and no before- of packages installed with --rootdir run with host commands. This means cleanup will be mostly before- and initialization mostly after-.

No good idea how to deal with hooks that need data from package, like $register_shell. Maybe add trigger:register-shell event, and add to repodata dict of events with dict of variables, then call hook once per package. Such event should allow to migrate from triggers to hooks without rebuild of packages. Maybe keep triggers (but run before and after transaction), as collapsing them is tricky and gain is much smaller than from rebuilding caches once.

[ericonr]

New hooks design should solve void-linux/void-packages#22817 ?

[pandom79]

Hi guys,
will we be informed when it is ready?
Good job

[Duncaen]

There is no ETA, if it happens it will be in the changelog and most likely announced on the website.

[pandom79]

There is no ETA, if it happens it will be in the changelog and most likely announced on the website.

ok. thanks

[pandom79]

I'm interested to develop this feature. Where and who could i ask info about it?

[pandom79]

I'm developing this feature. I could know some things before to develop it totally.

1. What should be the hooks path?
   At the moment, i set it in xbps.h
   #define XBPS_HOOKS_PATH XBPS_SYSDEFCONF_PATH "/hooks"

2. I'm following libalpm as model with a little differences
   This is the model :

[Trigger] 
Operation = Install|Upgrade|Remove (Required, Repeatable)
Type = Path|Package (Required)
Target = <Path|PkgName> (Required, Repeatable)

[Action]
Description = ... (Optional)
When = PreTransaction|PostTransaction (Required)
Exec = <Command> (Required)
Depends = <PkgName> (Optional)
AbortOnFail = True|False (Optional, PreTransaction only)

The Trigger and Action sections are not repeatable.
I don't consider them but they improve the hook readability.
I advice leave them.
I only consider the properties.
The repeatable of the "Operation", "Target" and "When" properties should meet our needs.
Each hook will be validate according this model, otherwise, i show the error and skip it.
The Type and Target properties are required.
Do we want delete this constraint?
By this way, if these properties are not defined the hook will be always runned.

What do you think about it?

[eoli3n]

@pandom79 nice ! I wait for that PR, it would be great to create pre upgrade zfs snapshot and post upgrade flatpak update !

The Trigger and Action sections are not repeatable.

Why not following the exact same syntax ? it would let us use pacman hooks as is.

[pandom79]

@pandom79 nice ! I wait for that PR, it would be great to create pre upgrade zfs snapshot and post upgrade flatpak update !

The Trigger and Action sections are not repeatable.

Why not following the exact same syntax ? it would let us use pacman hooks as is.

The libalpm was taken as a model not a brutal copy.
During the develop, i wanted make it more simple because i haven't seen the reasons which you propose me.
On Void, we love the simple. (KISS)
In 4 years of Arch Linux, i never had to put more actions or triggers when i configured a pacman hook,
therefore, i thought to change it.
The arch linux users before switch to another distro take information for a similar mechanism.
It's incredible, look here https://www.reddit.com/r/Fedora/comments/dkntph/is_there_any_equivalent_of_pacman_hooks_in_rpmdnf/
The reason of that, it's very useful for multiple use cases.
We cannot live without it...:)

[eoli3n]

I like KISS as much as I love cross compatibility.
You're probably right, but in my experience "the same but not exactly" paradigm leads to user misunderstandings.

Yes it is a powerful feature !

[pandom79]

I like KISS as much as I love cross compatibility.
You're probably right, but in my experience "the same but not exactly" paradigm leads to user misunderstandings.

Yes it is a powerful feature !

I agree with you.
If you think that the current implementation should be changed,
please, send me an email (pandom79@gmail.com) with the suggested changes.
I'll be glad to accept your request. ;)