pacman hooks timing

jernst · 2018-03-23 00:10:06

When exactly during the installation of a package, are the pacman hooks invoked? It appears the sequence of events is:

pacman obtains to-be installed package file
pacman performs various checks that the package can likely be installed
pacman untars the package and dumps its files into the file system
pacman runs the install script, if any

(I might be missing other events.) Do the hooks run between 2 and 3 (probably not), between 3 and 4 (I guess so?) or at the end?

Trilby · 2018-03-23 00:17:46

man alpm-hooks wrote:

libalpm provides the ability to specify hooks to run before or after transactions

Allan · 2018-03-23 00:44:50

Between 2 and 3 and after 4.

amish · 2018-03-23 01:26:37

What if I am installing new package and it has hook file with pre-transaction hook?

i.e. (roughly)
Operation=Install
Type=Package
When=PreTransaction

Will hook run?

apg · 2018-03-23 01:33:33

no

eschwartz · 2018-03-23 02:57:51

amish wrote:

What if I am installing new package and it has hook file with pre-transaction hook?

Think about it... the hook doesn't exist until after the transaction, but it specifies that it should be run *before* the transaction.

So once the packages have been untar'ed and the newly installed hooks are read out for PostTransaction actions, the hook in question is no longer relevant.

Trilby · 2018-03-23 03:02:20

Depends = flux-capacitor
Depends = delorean
When = 88mph

Last edited by Trilby (2018-03-23 03:03:08)

jernst · 2018-03-23 03:10:40

Trying to transcribe this to the wiki, and adding one level of detail: https://wiki.archlinux.org/index.php/Pa … erstanding

Corrections and completions very much appreciated.

amish · 2018-03-23 03:55:37

Eschwartz wrote:

Think about it... the hook doesn't exist until after the transaction, but it specifies that it should be run *before* the transaction.
So once the packages have been untar'ed and the newly installed hooks are read out for PostTransaction actions, the hook in question is no longer relevant.

Yes so hooks can not completely replace "install" scripts that we specify in PKGBUILD.

May be pacman can look for hook files just before untar, untar them first and run them (PreTransactions only) and then proceed normally?

Just a thought!

Last edited by amish (2018-03-23 03:56:49)

amish · 2018-03-23 04:01:27

jernst wrote:

Trying to transcribe this to the wiki, and adding one level of detail: https://wiki.archlinux.org/index.php/Pa … erstanding
Corrections and completions very much appreciated.

In wiki - you wrote:

# if pacman {{ic|PreTransaction}} hooks are apply, they are executed

This is not true for freshly installed pacakge. May be we can put some note there?

Scimmia · 2018-03-23 04:08:37

Hooks aren't meant to replace install scripts completely. I can't think of an instance where you'd want to run a hook pre-transaction for the package that installs the hook.

amish · 2018-03-23 04:24:59

The current implementation has a caveat.. (in my opinion)

Preupgrade or Preinstall transaction actually run hooks of previous version and not the version being installed.

(rough example of hook file)

[Trigger]
Operation=Install
Operation=Upgrade
Type=Package

[Action]
When=PreTransaction
Exec=blah-of-v1

What if blah-of-v1 was buggy and can have nasty effects?

If hooks are untar'ed before running transaction this situation can be taken care of.

If blah-of-v1 was not buggy - new version will keep it as it is.

if blah-of-v1 was buggy - new version will replace it with blah-of-v2 and new bug-free version will run.

This also makes it more correct, otherwise Preinstall / Preupgrade are actually Prereplace for older versions.

PS: But then blah-of-v2 may not be available yet. (needs more thought)

Update:
1) May be dont run PreTransaction hooks before untar but just after untar - if package added / modified any PreTransaction hook.
2) May be we can add "When=FreshInstall" hook which run only for fresh Install cases? (just after untar but before posttransaction hooks)

OR
3) If package did not exist in the system and it has "When=PreTransaction" / "Operation=Install" hook then this hook should be run just after Untar and before PostTrasaction?

Last edited by amish (2018-03-23 04:48:43)

Scimmia · 2018-03-23 06:16:34

I see the issue now, you're completely misunderstanding what hooks are for. Take a look at the fontconfig hook, it runs whenever any fonts are installed by any package. Same thing for the .desktop database, icon cache, etc.

It is NOT meant to totally replace the install scriptlets.

amish · 2018-03-23 07:58:52

Well in that case this kind of is misleading. (may be i misunderstood)

https://wiki.archlinux.org/index.php/PKGBUILD#install

pacman#Hooks provide similar functionality.

It gives impression that ".install" scripts have (new) alternate and may be used instead. I was under impression that eventually ".install" scripts will be done away with in distant future.

Probably we should make it more clear that install scripts are package specific and hooks are on global level. (independent of the package and for tasks which are common among packages)

Allan · 2018-03-23 09:43:50

amish wrote:

Well in that case this kind of is misleading. (may be i misunderstood)
https://wiki.archlinux.org/index.php/PKGBUILD#install
pacman#Hooks provide similar functionality.
It gives impression that ".install" scripts have (new) alternate and may be used instead. I was under impression that eventually ".install" scripts will be done away with in distant future.
Probably we should make it more clear that install scripts are package specific and hooks are on global level. (independent of the package and for tasks which are common among packages)

If you have 100 packages with the same install script, you should create a hook. If you have one, use an install script.

amish · 2018-03-23 10:15:41

Yes thats what I meant that it should be made more clear somewhere.

Like:

pacman#Hooks provide similar functionality for packages having common scripts.

Trilby · 2018-03-23 11:40:44

Most of the caveates/confusion here seem to be thinking of hooks with the owning package as the target. While this is undoubtedly possible, it does not seem to be their purpose. Out of 26 hooks I have installed, I can't find a single one that has itself as a target.

As for the wiki ... it's a wiki. That note was added there by an over-eager user suggesting that install scripts were deprecated by hooks "mention Pacman hooks, which often deprecate .install scripts in many cases". This was completely removed by Lahwaacz within 4 hours (rightfully, because it was nonsense). It seems though that Lahwaacz didn't want to completely nuke the idea, and added back a much more inoccuous cross-reference to the hooks page suggesting only similarity (not that hooks replace install scripts).

If one wants to understand the extent of similarity, one should follow that link and read the hooks page, at which point the distinctions between install scripts and hooks should be clear. Note that even the present cross-reference note says they are similar, not identical. But I'd be all for dropping that cross reference entirely.

Last edited by Trilby (2018-03-23 11:50:19)

eschwartz · 2018-03-25 06:01:06

amish wrote:

Eschwartz wrote:
Think about it... the hook doesn't exist until after the transaction, but it specifies that it should be run *before* the transaction.
So once the packages have been untar'ed and the newly installed hooks are read out for PostTransaction actions, the hook in question is no longer relevant.
Yes so hooks can not completely replace "install" scripts that we specify in PKGBUILD.
May be pacman can look for hook files just before untar, untar them first and run them (PreTransactions only) and then proceed normally?
Just a thought!

That's why install scripts exist.

Hooks are not usually provided by the package that needs them, they are provided by the package that installs a shared service used by many other packages. For example, the texinfo package provides a pacman hook which runs PreTransaction and PostTransaction, and triggers on `info` documentation. The PreTransaction hook gets rid of the index for to-be-deleted files, and the PostTransaction hook adds or updates new ones.

Packages do not usually need to do something *before* they themselves are installed for the first time. If they do, then by definition they are almost certainly not generic enough to be run before many other packages are installed for the first time.

Trilby wrote:

Most of the caveates/confusion here seem to be thinking of hooks with the owning package as the target. While this is undoubtedly possible, it does not seem to be their purpose. Out of 26 hooks I have installed, I can't find a single one that has itself as a target.

Well. The linux package provides two different hooks, both of which are triggered by file targets including the files in that very package.

The only reason they are not install scripts, is because 1) depmod should be also triggered by packages that provide thirdparty kernel modules, and mkinitcpio should also be triggered by anything that provides mkinitcpio hooks, and 2) mkinitcpio cannot be run right after the kernel is updated, since it can end up creating a mkinitcpio image containing partially updated system components that have broken libraries.

amish · 2018-03-25 06:36:08

Query with respect to recent modification to wiki

https://wiki.archlinux.org/index.php/Pa … .2Fremoval

4.2 - pacman deletes all the files from a pre-existing version of the package (in the case of an upgraded or removed package)
4.3 - pacman untars the package and dumps its files into the file system (in the case of an installed or upgraded package)

Does this happen one package at a time. i.e. for each package, delete all files related to the package and then untar files related to package (one by one)

Or first delete files for all packages and then untar files for all package?

I believe that it would be one by one but just asking for clarity.

Also what would happen if power fails just after deleting files - say when - kernel is being upgraded?
I believe system wont boot because there is no kernel (unless I have another kernel too)?

Can we make it atomic and minimize the damage? i.e. delete one file and untar one file? or even better replace the file? so that either old or new version of that file will remain. (or is it already so?)

1. Check old file of package in new package.
2. If it does not exist in new package - delete it (if not a backup file)
3. If it exists in new package - replace it atomically.
4. Install files that are in new package but were not in old package.

This way damage would be limited to based on how the filesystem journal works.

Last edited by amish (2018-03-25 07:09:31)

eschwartz · 2018-03-25 06:42:18

amish wrote:

Does this happen one package at a time. i.e. for each package to , delete all files related to package, untar files related to package (one by one)
Or first delete files for all packages and then untar files for all package?
I believe that it would be one by one but just asking for clarity.

IIRC yes, that's why I edited that into the wiki. Otherwise I would have lifted that section out of the looped subsection.

Also what would happen if power fails just after deleting files - say when - kernel is being upgraded?
I believe system wont boot because there is no kernel (unless I have another kernel too)?
Can we make it atomic and minimize the damage? i.e. delete one file and untar one file? or even better replace the file? so that atleast one version remains. (or is it already so?)
This way damage would be limited to based on how the filesystem journal works.

You've hit on exactly why power failure during an update is bad luck.

Atomicity of updates is something that has been requested for pacman, but the general feeling is this is probably out of scope and better provided by pacman hooks + dedicated tools like btrfs/snapper.

Deleting one file and untar'ing one file wouldn't really help... you'd end up with mismatched files and that is without factoring in the fact that most kernel files are in a versioned modules directory.

amish · 2018-03-25 07:28:57

Ok so instead of delete and then add, why cant we have overwrite and then delete*

*delete files which are not in new package.(but were in old package)

That may make it bit atomic?

eschwartz · 2018-03-25 11:31:27

"bit atomic"

Is that like "sort of pregnant"?

This is a binary concept here, if it isn't actually atomic then the whole process does you no good. You'd still overwrite files one by one, and any attempt to use the software during that time would be horribly broken in concept. Except even worse, because if the software is not properly versioned (shared libraries have sonames, but not every project uses them and there are other things besides sonames, things that aren't versioned) then you end up trying to run mismatched versions. A failure due to missing components is a lot more honest, and sane solutions like atomically snapshotting filesystems already achieve the only useful outcome of atomic package updates -- which is emergency recovery.

amish · 2018-03-25 12:41:55

I used word "bit atomic" to indicate that I am aware that its not completely atomic (and that I am aware that it can still break the system)

But having ALL the files of a package missing due to power failure will surely break things when system reboots.

And having ONLY 1 file missing (or having some files of previous version) may give little chance/hope of not breaking things outright. Because most of the times minor version updates are backward compatible. In general, frequency of major version update is less than frequency of minor version update. Often its just "pkgrel" change. Hence there still remains good probability that things may not break at all.

So in current case - if power fails - package will not work 100% because all its files are missing
In overwrite then delete case - package may still function based on how and what failed. (mostly if new version is backward compatible)

In both cases ofcourse user must repair things immediately.

Last edited by amish (2018-03-25 12:53:18)

Allan · 2018-03-25 12:43:03

In a power outage, your files probably have not synced to disk anyway....

amish · 2018-03-25 12:47:04

Allan wrote:

In a power outage, your files probably have not synced to disk anyway....

Yes so in my case older version will still remain on disk ...and not break things at all.

But if you "delete" all files first which may be faster in sync (as its just inode marking) - high chance that files would definitely go.

Last edited by amish (2018-03-25 14:23:58)

Arch Linux

#1 2018-03-23 00:10:06

pacman hooks timing

#2 2018-03-23 00:17:46

Re: pacman hooks timing

#3 2018-03-23 00:44:50

Re: pacman hooks timing

#4 2018-03-23 01:26:37

Re: pacman hooks timing

#5 2018-03-23 01:33:33

Re: pacman hooks timing

#6 2018-03-23 02:57:51

Re: pacman hooks timing

#7 2018-03-23 03:02:20

Re: pacman hooks timing

#8 2018-03-23 03:10:40

Re: pacman hooks timing

#9 2018-03-23 03:55:37

Re: pacman hooks timing

#10 2018-03-23 04:01:27

Re: pacman hooks timing

#11 2018-03-23 04:08:37

Re: pacman hooks timing

#12 2018-03-23 04:24:59

Re: pacman hooks timing

#13 2018-03-23 06:16:34

Re: pacman hooks timing

#14 2018-03-23 07:58:52

Re: pacman hooks timing

#15 2018-03-23 09:43:50

Re: pacman hooks timing

#16 2018-03-23 10:15:41

Re: pacman hooks timing

#17 2018-03-23 11:40:44

Re: pacman hooks timing

#18 2018-03-25 06:01:06

Re: pacman hooks timing

#19 2018-03-25 06:36:08

Re: pacman hooks timing

#20 2018-03-25 06:42:18

Re: pacman hooks timing

#21 2018-03-25 07:28:57

Re: pacman hooks timing

#22 2018-03-25 11:31:27

Re: pacman hooks timing

#23 2018-03-25 12:41:55

Re: pacman hooks timing

#24 2018-03-25 12:43:03

Re: pacman hooks timing

#25 2018-03-25 12:47:04

Re: pacman hooks timing

Board footer