Univention Bugzilla – Bug 47356
deb-triggers blocks update due to temporarily unconfigured package
Last modified: 2018-07-25 13:56:36 CEST
After Bug 47196 was fixed, some Jenkins scenarios failed upgrading from UCS 4.3-0 (Errata 0) to 4.3-1-errata-test (repository: updates-test). Like so: ================================================================ Preparing to unpack .../06-ldap-utils_2.4.45+dfsg-1~bpo9+1A~4.3.0.201807101905_amd64.deb ... Unpacking ldap-utils (2.4.45+dfsg-1~bpo9+1A~4.3.0.201807101905) over (2.4.45+dfsg-1~bpo9+1A~4.3.0.201801091316) ... [... and then some random other package triggers univention-config by installing a file to /etc/univention/templates/info:] Setting up perl (5.24.1-3+deb9u4) ... dpkg: dependency problems prevent processing triggers for univention-config: univention-config depends on ldap-utils; however: Package ldap-utils is not configured yet. dpkg: error processing package univention-config (--configure) [... repeats ~ 50 times] dependency problems - leaving triggers unprocessed dpkg: too many errors, stopping Errors were encountered while processing: univention-config univention-config univention-config univention-config univention-config [... repeats ~ 50 times] ================================================================ And the update aborts.
https://manpages.debian.org/stretch/dpkg-dev/deb-triggers.5.en.html recommends using "interest-nowait", which might fix this problem. *But* Jürn just pointed out that the trigger function defined in univention-config.postinst is responsible to run "univention-config-registry update". Now, if a univention package update defines a new UCR template or variable, it may not be available immediately. We are currently unsure about this. Reading the documentation in triggers.txt (linked in https://wiki.debian.org/DpkgTriggers), it looks like the triggers are run after the triggering package "T" (which wants to register a new UCR template/variable) would normally go into the state "installed". As some other package "I" (univention-config in this case) is interested to get notified, the package "T" is put into "triggers-awaited" state instead (and "I" is put into "triggers-pending"). Then, at some later point in time, the triggers function defined in the postinst of "I" is run. We didn't yet find out at what point this happens. For our case two things follow: 1) Jürns concern regarding "UCR update" should not actually be a problem for us, because the package "T" can't rely on this UCR commit during its postinst run anyway. The triggers are executed after the postinst run in all cases. 2) perl may actually not be the triggering package here After dealing with these theoretical concerns, we made an experiment by adjusting changing univention-config.triggers to "interest-noawait". Actually we took a UCS 4.3-0 system and adjusted /var/lib/dpkg/triggers/File to modify the "interest" type of univention-config to "noawait". After that the direct update to 4.3-1-errata-test worked.
325ca42965 | Relax trigger execution to "noawait" 006266b9f1 | Advisory My update from updates-test worked.
The tests are working again, fix looks goods. Due to bug 47372 the QA took a little bit longer, but now everything seems to be good. FIX: OK YAML: OK
<http://errata.software-univention.de/ucs/4.3/152.html>