Need better abstraction for abscripts, including triggers.

[Artoria2e5]

It's really sad (and quite normal) that all package managers we currently support has an implmentation for triggers. Being not strange at all, it's far better than what we have now, even better than the revised one in #34。

Additionally, different package managers pass fairly different args to the scripts. A common shell header should be added (personally I suggest /var/ab/headers/abscript.$ABPM in $ABPM's package).

Trigger Documentation

• RPM: http://rpm.org/wiki/FileTriggers (And http://rpm.org/api/4.4.2.2/triggers.html for package actions)
• DPKG: man 5 deb-triggers, http://stackoverflow.com/questions/15276535/dpkg-how-to-use-trigger

New abstractions required

• Package State/Operation to perform if defined by the package manager, so we can deal with it using case.
• await / noawait triggers like in dpkg. Missing such thing makes the ab3 support for dpkg triggers worse than the one in ab2.
• RPM package triggers may be used for RPM <= 4.13 to emulate FIleTriggers, e.g. using pm_whoprov.
• DPKG has a named trigger system. In the #34 interest, it can be detected by testing if ${1:0:1} is /.

Notes

RPM has an internal Lua interpreter (-p <lua>) , but I can't find it to be anyhow useful.

Maybe we should implement the header in plain POSIX shell (at most busybox ash with bash extensions), so we can make more effective bootstraps. Therefore, arrays may not be used, and [[ foo == pattern ]] must be rewritten with case foo in (pattern).

For unsupported ones, we can have the current one (with faked never-really-working await/noawait and a warning) as a fallback.

PM support reference

DPKG	RPM	Autobuild3	Pacman
interest path	%transfiletrigger*	no magic-comments needed
interest-noawait	%filetrigger*	#ab:...:trigger_noawait:...
interest-await	%transfiletrigger*	#ab:...:trigger_await:...
interest name	stub: ab	/var/ab/triggers/$name/$PKGNAME
activate	stub: ab	stub: noawait
activate-noawait	stub: ab	/var/ab/triggers/$name/* (symlink)

Major changes:

• autobuild/triggers is a directory with a bunch of source-able trigger scripts. The installation path is shown in the table.
• Extra patching in deb postinst!

Notes:

• I once considered the possiblity of emulating RPM triggers with files, by, say, dynamically programming the package to create stuff like /var/ab/rpm/trigger-store/$name/$PKGNAME.

  But I don't think rpm tracks files created during postinst. nah.

• RPM provides some fine-grained control of triggers -- in,un,postun. Perhaps we should add these to our abstraction (→ $SRCDIR/autobuild/triggers/in/). Be advised, un and postun triggers may not be async in dpkg.

TODO: States, arg scheme

[Icenowy]

The triggers support in ab3 is designed for RPM usage, but with a DPKG-like grammar. DPKG triggers in os2 is directly ported to os3, without any changes.

The RPM-style triggers support is serious, but it's not extensible at all.The DPKG-style triggers is open and extensible, but not suitable for RPM.So... I made such a bad wheel.

[MingcongBai]

@Icenowy Well now let's fix this then...

[Artoria2e5]

@Icenowy Updated. Working on the correspondence.

[Artoria2e5]

Can we nullify the current stubs for dpkg and only use them in rpm? (I am quite lazy now so)

[MingcongBai]

Can we nullify the current stubs for dpkg and only use them in rpm? (I am quite lazy now so)

Explain this?

[Artoria2e5]

Basically redirect the results of all the /var/ab/triggered/... to somewhere other than postinst itself. In rpm do an extra cat to include the results.

[MingcongBai]

Got it.