Bug#781742: initramfs-tools use of triggers and DPKG_MAINTSCRIPT_PACKAGE
Resending with a more obvious subject.
The workaround I describe in the final paragraph does seem to work, but
I'm not sure that's the best way to go.
On Mon, 2015-05-04 at 15:31 +0100, Ian Campbell wrote:
> (CC initramfs-tools@packages, context is flash-kernel invocation not
> being deferred via triggers during upgrade and ultimately running
> several times in a dist-upgrade)
>
> On Sat, 2015-04-04 at 10:49 +0100, Ian Campbell wrote:
> > At first glance it seems like invocations via the initramfs-tools hooks
> > are not being deferred.
>
> This is because initramfs-tools.postinst contains:
> # Regenerate initramfs whenever we go to dpkg state `installed'
> if [ "x$1" != xtriggered ]; then
> # this activates the trigger, if triggers are working
> update-initramfs -u
> else
> # force it to actually happen
> DPKG_MAINTSCRIPT_PACKAGE='' update-initramfs -u
> fi
>
> and flash-kernel uses [ -n "$DPKG_MAINTSCRIPT_PACKAGE" ] when deciding
> to defer to a trigger. So the invocations of flash-kernel
> via /etc/initramfs/post-update.d/flash-kernel end up never being
> deferred.
>
> I don't think initramfs-tools is wrong to do this per-se, but it does
> mean that anything hooked off the post-update.d hooks cannot reliably
> use triggers (dpkg-trigger uses $DPKG_MAINTSCRIPT_PACKAGE itself).
>
> flash-kernel itself does something similar, but instead of manipulating
> DPKG_MAINTSCRIPT_PACKAGE it instead sets FLASH_KERNEL_NOTRIGGER=1 and
> keys off that.
>
> It seems like the best solution would a patch to switch initramfs-tools
> to a similar scheme, would such a patch be accepted?
>
> If not then I will arrange for /etc/initramfs/post-update.d/flash-kernel
> to signal to f-k somehow that triggers should be used despite the lack
> of DPKG_MAINTSCRIPT_PACKAGE.
>
> Ian.
>
>
Reply to: