Chris Hofstaedtler, le ven. 03 avril 2026 12:04:01 +0200, a ecrit: > On Fri, Apr 03, 2026 at 02:23:13AM +0200, Cyril Brulebois wrote: > > Cyril Brulebois <[email protected]> (2026-04-03): > > > Your libmount1-udeb binary package picked up a dependency on libsystemd0, > > > making it non-installable. Known-OK version includes 2.41.3-4. Known-KO > > > version seems to include 2.42~rc2-1 (which was published to experimental, > > > but that's currently not being tracked/combined with unstable to check > > > udeb installability there unfortunately). > > > > A very quick investigation suggests this might be due to upstream commit > > 8bdc2546d38979ca65fa9bfd1bbd6e7b985c69db (first published via the > > upstream/2.42_rc1 tag): > > > > > > https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?h=8bdc2546d38979ca65fa9bfd1bbd6e7b985c69db > > > > That'd be the sd_* addition to the libmount/ subtree, resulting in the > > following symbols being required by libmount.so.1.1.0 now (in other words, > > definitely not a spurious dependency): > > > > U sd_device_get_property_value@LIBSYSTEMD_240 > > U sd_device_new_from_devname@LIBSYSTEMD_251 > > U sd_device_unref@LIBSYSTEMD_240 > > > > I'm not sure how to best address this. > > Me neither. I see the new symbols are used in an #ifdef > USE_LIBMOUNT_UDEV_SUPPORT. Now I imagine the installer wants to use > udev support, but I don't know. > If these symbols are part of the udev API, are they available in > some udev udeb? If not, maybe they should be?
We could as well just add a libsystemd1-udeb? I guess more and more software will sooner or later use libsystemd. Samuel
