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

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

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.

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