Am Freitag, den 11.09.2009, 11:30 +0200 schrieb Xavier:
On Fri, Sep 11, 2009 at 11:18 AM, Marc - A. Dahlhaus [ Administration | Westermann GmbH ] <mad@wol.de> wrote:
Hello List,
currently i'm working on adding a trigger infrastructure to libaplm/pacman to get rid of workload during upgrades or installations that runs more than a single time.
Good examples for such jobs would be:
- depmod after module installations - mkinitramfs after module installations - catalog-updates for fonts or infopages etc...
My current plan is to create a helper script called "alpmtrigger" wich handles the work of setting the triggers and executing the triggers after pacman is done with installation.
How would it work? Draft:
A package that adds a trigger to the system installs a trigger script that do all the work needed into a "/usr/share/pacman/alpmtrigger" dir.
inside of a packages install-helper we would call "alpmtrigger pkgtrigger" to set the trigger "pkgtrigger" active. alpmtrigger would do "touch /var/somewhere/alpmtrigger/pkgtrigger" wich would create the file if it not exists already.
A hook to execute "alpmtrigger" (without params?) would need to be added after the _alpm_run_chroot(root, "/sbin/ldconfig"); call in function _alpm_ldconfig inside of lib/libalpm/util.c to actualy scan the contents of /var/somewhere/alpmtrigger, and for each filename in it check if /usr/share/pacman/alpmtrigger/filename exists and if it is and is executable run the trigger. After the trigger is done and retuned without error, the file /var/somewhere/alpmtrigger/filename gets removed.
Any suggestions, comments or somebody else working on such a thing?
see http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
I think this design concept will not work in real world use cases. Problems i spotted: - Hooks should be provided by the packages that actualy contain the tools that the hook has to do. - Hooks should get installed by placing a file into an apropriate location and not by adding them to a single config-file (manual intervention of the user required or every new hook a new hooks package has to be made) - I don't think that so many points to add a hook are really needed in a real world... In the end it looks like this is a design concept to reimplement the install-helper functionality but decouple it from the actual package. Looks like a big step backwards for me...
Before implementing anything, I would like to see the maximum of actions which are currently done in real package scriptlets converted to the new hook system. So that we are sure we have a good coverage.
nothing to add here, as this is an arch only argument, i don't use arch and pacman development should done with other things than "how useful is XYZ for arch" in mind IMO...
Scriptlets are just another case of code duplication which is my big enemy. Once we are confident enough that the proposed system achieves that, I think I would be interested and motivated to do the implementation.
Yeah, and you would get rid of the hated duplication if you have one single point (a trigger script) to add this currently duplicated code to and select the things to do inside the packages that needs the work to be done, or wouldn't you? ;-) I think that a solution is needed that removes work from the package maintainers and not add another thing they have to think about and have to collaborate on like the single hook package what would be fruit of implementing the Packman_Hooks thing... By the way, i don't wanted to be rude with this, my english isn't that good... Marc