Problems upgrading package with changing dependencies

9 views
Skip to first unread message

Bryan Evenson

unread,
Feb 9, 2022, 10:18:50 AM2/9/22
to opkg-devel
All,

I'm seeing a complex issue with upgrading a package with a changed dependency.  I think this works for other package managers and I'm wondering what a proper workaround would be for opkg.

I have a yocto-based system that is on the morty branch that I am upgrading to the dunfell branch.  glib-2.0 is half-installed after the upgrade.  Here's the chain of events as best I can tell that create the issue:

1. Device is installed with an image based on the morty branch which uses glib-2.0.  The glib-2.0 package depends on libffi.
2. Between morty and dunfell, libffi updated from libffi6 to libffi7.
3. During the glib-2.0 package upgrade, glib-2.0 forces its dependencies to upgrade prior to upgrading itself.  This removes libffi6 and installs libffi7.
4. After glib-2.0's dependencies have upgraded, glib-2.0 runs its postrm script.  This calls 'gio-querymodules'.  At this point glib-2.0's files have not been updated, so the old version of gio-querymodules runs which is expecting libffi6 to be present.  The postrm script fails and glib-2.0 remains half-installed.

If I'm reading the code correctly at [1], opkg does not install the new files until after the old files have been removed.  The debian standard is to install the new files after the preinst step and create backups of the old files, then run the postrm step.  If opkg were to do this, then gio-querymodules would have been updated prior to the postrm step and would have executed successfully.

I have things operational on my system by adding a preinst step to glib-2.0 that removes the old postrm script from the device.  My system doesn't use the GIO modules and there is nothing in the postrm script that actually needs to execute for my system.  However, this is a very crude approach.

Short of rewriting opkg to install the new files and create backups of the old files according to the debian standard, does anyone know of a cleaner way to fix this problem?

Thanks,
Bryan


Alex Stewart

unread,
Feb 10, 2022, 4:22:10 PM2/10/22
to Bryan Evenson, opkg-...@googlegroups.com
Hey Bryan,

I think you're running up against a policy difference between dpkg and
opkg. AFAIK, the design decision to not have opkg keep around the *old*
files during an upgrade is intentional and intended to make opkg's
operational memory footprint small enough to be palatable to embedded
devices.

The yocto community itself has been hesitant to approach runtime package
upgrades in any serious capacity - as you probably gathered from
akanavin's rebuttal on the yocto list. You're the only person I've heard
of who is brave enough to try runtime dist-upgrades across yocto
releases. :)

So I suppose, from a yocto perspective, the responsibility lies with the
glib package's maintainer scripts to be *intelligent* enough to figure
out what libffi content is available and "do the right thing".
Obviously, that isn't a generic solution.


I imagine that RPM might be able to handle your dist-upgrade correctly;
though I expect that may be a non-starter if you have already-deployed
morty systems using opkg.


If you can figure out a clever way to make opkg behave like dpkg without
dramatically increasing the memory/storage usage during an upgrade (and
without totally duplicating the upgrade codepaths), I'd be happy to hear
it. I expect you're probably working at the wavefront of opkg
development in this regard.


Hope that helps,
> <https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/tree/libopkg/opkg_install.c?h=v0.5.0&id=8b8819095b19d5b7f83f66b35e8b4e8f1bf80b6a*n414__;Iw!!FbZ0ZwI3Qg!8kmD__5Cb65CUYF3yUDXDap0wgt5fK6p-SQqUEHQRq3SW_LIdHuM9ztGb8Ii-Vc$>
>
> --
> You received this message because you are subscribed to the Google
> Groups "opkg-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opkg-devel+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opkg-devel/CAOfHXQxrQgHfCZ5AxgchT03a77%3Dn5aWbYcS8S3X3tVic5qah4Q%40mail.gmail.com
> <https://urldefense.com/v3/__https://groups.google.com/d/msgid/opkg-devel/CAOfHXQxrQgHfCZ5AxgchT03a77*3Dn5aWbYcS8S3X3tVic5qah4Q*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSU!!FbZ0ZwI3Qg!8kmD__5Cb65CUYF3yUDXDap0wgt5fK6p-SQqUEHQRq3SW_LIdHuM9ztGsmreYsg$>.

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

alex.s...@ni.com

Bryan Evenson

unread,
Feb 10, 2022, 5:20:31 PM2/10/22
to Alex Stewart, opkg-devel
Alex,

Thanks for the confirmation.  I suspect you are correct and this would work without issue under RPM.  I think I'll stick with my solution for now by deleting the postrm in the preinst step.  It works just fine for me.

Unfortunately, I may agree with the design decision not to create backup copies so opkg works on smaller footprint devices.  I'm hesitant to start changing that functionality myself, as I feel I'd likely cause more new problems than I would fix.

I am actually kind of surprised that I'm not hearing of others doing dist-upgrades.  The package management for upgrade management was one of the reasons I chose yocto over something like buildroot for this device.  I've been doing remote upgrades for a headless device since all the way back to the dylan branch.  I have the Linux kernel and the bootloader setup as r/w partitions and will even upgrade those without issue.  Personally, I think a commitment for a dist-upgrade to work for core-image-minimal and one or two other example images would be good for the project.  But, I guess they would need the people to work to maintain and test that, which may be the bigger issue.

Thanks,
Bryan

Alex Stewart

unread,
Feb 10, 2022, 8:34:01 PM2/10/22
to Bryan Evenson, opkg-devel
True. For what it's worth, NI also does the equivalent of runtime
kernel- and dist-upgrades; but we do it by swapping out the whole rootfs
in an A/B(-ish) boot scheme. Part of the rationale for that is historic
momentum, but we also get more guaranteed stability out of swapping the
boot image wholesale - which helps when our customers are deploying
their embedded devices up windmill turbines and into hard vacuum. :P

I get the impression that many others in the community are in similar
positions, where they would prefer to invest in an A/B boot scheme (eg.
RAUC, or Mender, or a home-rolled solution) over doing individual
package upgrades.

On 2/10/22 16:20, Bryan Evenson wrote:
> Alex,
>
> Thanks for the confirmation.  I suspect you are correct and this would
> work without issue under RPM.  I think I'll stick with my solution for
> now by deleting the postrm in the preinst step.  It works just fine
> for me.
>
> Unfortunately, I may agree with the design decision not to create
> backup copies so opkg works on smaller footprint devices.  I'm
> hesitant to start changing that functionality myself, as I feel I'd
> likely cause more new problems than I would fix.
>
> I am actually kind of surprised that I'm not hearing of others doing
> dist-upgrades.  The package management for upgrade management was one
> of the reasons I chose yocto over something like buildroot for this
> device.  I've been doing remote upgrades for a headless device since
> all the way back to the dylan branch.  I have the Linux kernel and the
> bootloader setup as r/w partitions and will even upgrade those without
> issue.  Personally, I think a commitment for a dist-upgrade to work
> for core-image-minimal and one or two other example images would be
> good for the project.  But, I guess they would need the people to work
> to maintain and test that, which may be the bigger issue.
>
> Thanks,
> Bryan

Reply all
Reply to author
Forward
0 new messages