[arch-general] Problem with pacman hooks, alphabetic order.

[Carsten Feuls]

Hello Everybody,

I have some trouble with pacman hooks.
Arch is going to use pacman hooks in every package.
etckeeper was one of the first package that use pacman hooks, without any 
trouble.
But now it becomes more tricky to run.
My Problem is that the pacman hooks run in alphabetic order.
And not in a Prirority order.

Here is an example:
[2016-05-13 23:49] [PACMAN] starting full system upgrade
[2016-05-13 23:49] [ALPM] running 'etckeeper-pre-install.hook'...
[2016-05-13 23:49] [ALPM] transaction started
[2016-05-13 23:49] [ALPM] upgraded ca-certificates-utils (20150402-1 -> 
20160507-1)
[2016-05-13 23:49] [ALPM] upgraded ca-certificates-mozilla (3.23-3 -> 3.23-4)
[2016-05-13 23:49] [ALPM] upgraded ca-certificates-cacert (20140824-2 -> 
20140824-3)
[2016-05-13 23:49] [ALPM] upgraded ca-certificates (20150402-1 -> 20160507-1)
[2016-05-13 23:49] [ALPM] upgraded glib2 (2.48.0-2 -> 2.48.1-1)
[2016-05-13 23:49] [ALPM] upgraded gnupg (2.1.12-1 -> 2.1.12-2)
[2016-05-13 23:49] [ALPM] upgraded nss (3.23-3 -> 3.23-4)
[2016-05-13 23:49] [ALPM] transaction completed
[2016-05-13 23:49] [ALPM] running 'check_pacfile.hook'...<<< My Own hook
[2016-05-13 23:49] [ALPM] running 'etckeeper-post-install.hook'...
[2016-05-13 23:49] [ALPM] running 'sync.hook'... <<< My Own hook
[2016-05-13 23:49] [ALPM] running 'texinfo-install.hook'...
[2016-05-13 23:49] [ALPM] running 'update-ca-trust.hook'...

In this log output we can see that etckeeper-post-install.hook is run before 
texinfo-install.hook and update-ca-trust.hook.
This is problematic because update-ca-trust.hook has update the
/etc/ssl/certs/java/cacerts
but this file was not commited by the etckeeper-post-install.hook because it 
is run to early.
The hooks run in alpabetic order.
I have tested to rename the etckeeper-post-install.hook to "99-etckeeper-post-
install.hook" but it does not help, because numbers run before characters.

How this problem could be solved?
Yes I know I can number every hook but I prefer a more upstream solution..


Sincerly Yours
Carsten Feuls




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20160514/047e4e46/attachment.asc>