Am Freitag, den 11.09.2009, 21:50 +1000 schrieb Allan McRae: > Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote: > > 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 ] <[email protected]> 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... > > > > Yes - but it is an actual example a script many people do run everytime > a package is updated. Obviously that would be a user provided hook and > not provided by the firefox package.
Interesting idea... > > > >> 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... > > > > That was an idea put out there because I basically do not want my info > page database updated (the most common install file task in Arch). This > could probably be achieved without a config file by removing execute > permissions from the hooks script or adding the script to the noextract > in pacman.conf, or in a multitud of ways. And now that concern has been > flagged, the wiki page can be adjusted. This exact point was raised already back on Fri 23 Jan 2009 by me... > These are the first comments made on the hooks idea since Februrary > despite much advertising of the potential of implementing this on my > behalf. It is good to see some real discussion of implementation issues > starting. Hope this discussion remains as productive as it is :-) Marc
