Alex,
> -----Original Message-----
> From: Alexander Kanavin <alex.kana...@gmail.com>
> Sent: Tuesday, February 8, 2022 4:38 PM
> To: Bryan Evenson <beven...@melinkcorp.com>
> Cc: Patches and discussions about the oe-core layer <openembedded-
> c...@lists.openembedded.org>
> Subject: Re: [OE-core] gio-querymodules: error while loading shared
> libraries: libffi.so.6: cannot open shared object file
>
> On Tue, 8 Feb 2022 at 21:36, Bryan Evenson <beven...@melinkcorp.com>
> wrote:
> > As best I can tell, this is breaking because libffi upgraded from libffi6 to
> libffi7. The old version of glib-2.0 depends on libffi6 and the new version
> of
> glib-2.0 depends on libffi7. Opkg starts to upgrade glib-2.0, but it first
> upgrades the dependent packages. This removes libffi6 and installs libffi7.
> Then, the postrm script runs for glib-2.0 using the old binaries. The gio-
> querymodules call then fails because it tries to load libffi6 which no longer
> exists. Even if I was able to defer upgrading libffi from libffi6 to libffi7
> until
> after glib-2.0 upgrades, I’d then run into a similar problem with the postinst
> script. In that case, gio-querymodules would fail because it would try to
> load
> libffi7 which would not be installed yet.
> > I understand that you don’t want errors to go through undetected. Would
> an appropriate error message, such as:
> > ${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/ ||
> echo “GIO module caching failed. You may need to manually update the GIO
> module cache.”
> > Work for you?
>
> That is not an error message, that is a warning message, and no, that is not
> appropriate either, because it's likely to go unseen, or discarded.
>
> I think you should study how desktop distributions handle this, both rpm-
> based and deb-based. How do their postinst/postrms look like, and in what
> sequence do they run?
For the Debian upgrade policy (flowchart here:
https://www.debian.org/doc/debian-policy/ap-flowcharts.html), successful events
occur in the following order:
1. Call prerm script from the old package
2. Call preinst script from the new package
3. Unpack new files and save backup of old files
4. Call postrm script from the old package
5. Delete old files
6. Call postinst script from the new package
7. Exit package upgrade
Opkg does something slightly different so it can operate with a smaller memory
footprint. For opkg the event order is:
1. Call prerm script from the old package
2. Call preinst script from the new package
3. Call postrm script from the old package
4. Unpack new files and delete old files
5. Call postinst script from the new package
6. Exit package upgrade
This saves space since there won't be a copy of every file in the package
during upgrade. It also reduces code complexity in opkg. But, it also means
the new files aren't available until the postinst stage. This is why I'm
seeing the failure that I am with opkg. So the postrm script is failing
because opkg isn't meeting the Debian policy.
However, I still think that a package upgrade should have a way to exit
gracefully for something that is an optimization and not required for
operation. In my case, my device isn't even using the GIO library and the
gio-querymodules serves no purpose. I don't know enough about the entire Glib
package to know If there is a way to make this functionality optional or not.
If there isn't, then I will continue with my own out-of-tree changes to fix the
operational problems I am seeing on my device.
Thanks,
Bryan
>
> As mentioned before, Yocto does not test or support mass-upgrades via
> package manager: if we want to fix this, we better do it properly from the
> start.
>
> Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161651):
https://lists.openembedded.org/g/openembedded-core/message/161651
Mute This Topic: https://lists.openembedded.org/mt/88979156/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
