Seeking help understanding source of package install scripts

[Bryan Evenson]

All,

I have a system I am attempting to upgrade that has an issue with the busybox package upgrade.  The original system is based off yocto-2.2 (morty) which was running opkg 0.3.3.  There was an error in the prerm script and I see the fix.  In my recent build I've fixed the prerm steps.  I'm testing the fixes by only upgrading busybox and its components (opkg update; opkg upgrade busybox-syslog busybox busybox-udhcpc busybox-httpd busybox-hwclock).  However, the error still persists and I've been able to confirm that the prerm step is not running any of my updates.  I've decompressed the updated busybox IPK and I've confirmed the busybox.prerm script in the IPK has my updates.

For the different upgrade steps (prerm, postrm, preinst, postinst), does opkg use the script from the new package or from one from the currently installed package?  If it is using a remnant from the currently installed package, is there a way to override this change?

Thanks,

Bryan

[Alex Stewart]

Hey Bryan,

By definition, the `prerm` script of the *old* package will run during
the upgrade operation. The prerm script of the *new* package isn't
considered until it is installed.

In dpkg, if the *old* package's prerm fails, dpkg will attempt to
recover by executing the *new* package's prerm [1]. Opkg isn't that
smart [2] and will only attempt the old-prerm. If you'd like to fix that
difference, I'd be happy to accept the PR. :)

If you need to fix an issue in prerm scripts that you have already
deployed into the wild (ie. you can't just reimage the machines), then
you might include a segment in the *new* package's preinst script which
tries to fixup machines that had bad prerm scripts.


[1]
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

[2]
https://git.yoctoproject.org/opkg/tree/libopkg/opkg_install.c?h=v0.5.0&id=8b8819095b19d5b7f83f66b35e8b4e8f1bf80b6a#n241


Hope that helps,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.s...@ni.com

[Bryan Evenson]

Alex,

Yes, this is an attempt to fix an issue that has been deployed.  The problem isn't in the prerm script, it's further down the line.  I did test updating the preinst script in the new package and that one is running.  I think it may still be early enough in the process to fix my problem.  I haven't got the fix ironed out yet, but I'm getting closer.

Thanks,

Bryan