[pacman-dev] [RFC] alpmtrigger: triggering events after all packages got installed...

[Marc - A. Dahlhaus [ Administration | Westermann GmbH ]]

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 at 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