Commits on Feb 27, 2024

1. Require glib2 version with g_once_init_enter_pointer symbol …

   glib2-2.79.0-2.fc40 added g_once_init_enter_pointer symbol and started
   to implant a reference on the symbol into applications via
   macros/in-lined functions included from glib2 header files. As
   a result, people upgrading to libdnf built against new glib2 but
   not upgrading glib2 at the same time will break dynamic linking of
   libdnf:
   
       Traceback (most recent call last):
         File "/usr/bin/dnf-3", line 61, in <module>
   	from dnf.cli import main
         File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in <module>
   	import dnf.base
         File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in <module>
   	import libdnf.transaction
         File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line 14, in <module>
   	from . import conf
         File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10, in <module>
   	from . import _conf
       ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer
   
   If glib2 versioned its symbols, rpm-build would inject an RPM
   dependency on the new glib2 versioned SONAME. However, this is not
   true, so we need to add a dependency on a minimal glib2 version
   manually.
   
   This issue is specific to not fully upgraded Fedora 40--41.
   This issue materializes in real life when mock installs a new libdnf into a
   bootstrap image based on a container image created before glib2-2.79.0-2.fc40
   
   https://bugzilla.redhat.com/show_bug.cgi?id=2265336

   

   ppisar committed Feb 27, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for b28875e
   • Browse repository at this point

   Copy the full SHA

   b28875e View commit details

   Browse the repository at this point in the history