Hello Allan, Am Freitag, den 11.09.2009, 20:38 +1000 schrieb Allan McRae:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
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.
Note that the design document I started is far from the final version... it was written to get discussion going and see what it could be used for.
...because of this i called it "design concept"...
Problems i spotted:
- Hooks should be provided by the packages that actualy contain the tools that the hook has to do.
Sure, but how is the opposite implied by what is written. Texinfo could (and should) provide the hook for updating the info databse, etc. I think this is you main point throughout and that seems to be a misunderstanding.
- 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)
From the design document, hook were added as a single file to the /etc/pacman.d/hooks.d/ directory. Adding the hook to a config file was to control if a user wanted that hook run. e.g. I really do not give a crap about updating the info page database so I would not set it to run. This can probably be improved (as could many things in that wiki page).
- I don't think that so many points to add a hook are really needed in a real world...
Here is a list of "hooks" that would be useful for Arch packaging. I know this is Arch specific but it should give an idea of real world use cases:
PostInstall: [gconf-install] - install gconf files [info-install] - add info pages to info directory file [man-install] - add man pages to db
PreRemove: [gconf-remove] - remove gconf files [info-remove] - remove info pages from info directory file [man-remove] - remove man pages from db
Transaction: [depmod] - can we do that as a hook [desktop] - update desktop database [font] - update the font cache [icon] - update gtk icon cache or xdg-icon-resource (how to choose?) [mime] - update mime database [tex-file] - texconfig-sys rehash [tex-font] - updmap-sys [vim] - update vim help tags [xpdf] - update /etc/xpdfrc
Install: [firefox] automatically run branding firefox script
The firefox one doesn't look like an example that would be used by anything other than the firefox package itself...
That covers actions that would use the majority of the proposed hook points.
<snip>
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...
You are free to provide your non-Arch use cases so we can see real world examples.
<snip> 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...
As I said above, I really do not understand why you think we would have to provide a hooks package and not provide hooks with the appropriate package.
Got to this impression because there is a single config file in which a hook has to be configured before it could be activated. The only way to achieve such a configuration in a way that works without user-intervention would be to wrap it all inside of one hook-package or things such a full system installation would end up without working hooks to execute. I apologize if my impression is wrong... In the end, my opinion of the Pacman_Hooks stuff is that it is well to complicated. I think that the implementation would be very complicated with respect to the configuration stuff... The points to which hooks could be added are more or less the same points on which the install-helper would provide already a point to add stuff. Looks like duplication to me, would be better to use what we have to achieve the goal. The only outstanding hook-target would be the transactional one which if i understand that correctly gets fired up after the transaction has completed. This is exactly the functionality i want to get into pacman. I don't care which way it gets implemented upstream in the end, as it's just the functionality that i want to get and use. Also to Xavier: your comments and hints were very useful :-) Could you review the revised version of my plan that i send a hour ago and give me some feedback about it? I want to implement a proof of concept version of alpmtrigger over the weekend if i get enough spare time from my wife and the baby ;-) and some Feedback would be very useful for me. thanks, Marc