Hi,

util-linux (specifically libmount) 2.42 and newer try to use the
udev database to resolve some data. This was introduced upstream in
this commit:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?h=8bdc2546d38979ca65fa9bfd1bbd6e7b985c69db

This new code uses various sd_* symbols. As a result, libmount
depends on libsystemd. libmount is also used by d-i, thus libmount
provides a udeb.

In #1132561 this was noticed, and I've temporarily disabled the new
code in src:util-linux. However, it seems like over time we will
need a libsystemd in d-i to satisfy such dependencies. Also the
util-linux packaging change to support this is fugly and I'd like to
remove it ASAP.

Please provide a libsystemd udeb so libmount (and possibly other
things in the future) can use libsystemd.

Thanks,
Chris

PS: debian-boot@ your opinion is obviously welcome.

Control: reassign -1 source:systemd-udeb

Mmmh what is the exact use case for this specific functionality in the
installer? It doesn't run systemd, and it will never do so, AFAIK.

Adding more udebs basically is a busywork generator. Each new package
is an unlimited, forever churn of busywork for everyone involved (d-i
team and package team), so I think we really really really really need
to be sure it's really needed before committing to it.

TTBOMK it runs udev. I don't know the inner workings of udev etc.,
but the data is probably there?

Sure, but so is running a separate no-systemd build in
src:util-linux. The other option that I have is to disable this
feature also in the non-udeb build.

Chris

Note that udev doesn't need it, so it would be needed only if some new
service in the installer needed that particular API for some
particular feature

Have you thought about splitting the udeb builds in a separate source
package? I've done that https://tracker.debian.org/pkg/systemd-udeb
with the blessings of the d-i team and while it's a bit of one-off
work to do the split initially, it then results in a much much much
lighter on-going maintenance burden, as the build is as minimal as it
can possibly be, and there are only a couple of uploads a year,
basically only when a new major version is out. It's been working very
well so far for me (and I hope for d-i too, given there's a lot less
work for them too, I've heard no complaints so far).

But if you don't want to do that, and you don't want to keep the
current separate stage1 build, then IMHO it's ok to just disable that
build flag globally, from the look of it, it seems to be just an
optimization anyway, so if it causes an additional burden on anyone,
it doesn't seem worth it to me.

Hi Chris,

Sorry I haven't answered earlier, I've had been thinking about this for
a while but haven't found time to articulate an answer while traveling.

Chris Hofstädtler <zeha@debian.org> (2026-04-13):

Thanks for the fix/workaround in src:util-linux by the way.

I'm not sure introducing such a udeb would make sense. I don't have any
kind of metric, but I would think large parts if not most of libsystemd
is about interacting with systemd-as-pid-1 anyway?


Cheers,

Hello,

Cyril Brulebois, le mar. 14 avril 2026 10:20:08 +0200, a ecrit:

Most probably, yes, but it seems to me simpler to maintain the existence
of libsystemd1-udeb that essentially says "no systemd is not running",
than building various udebs differently with a no-systemd option.

(at-spi2-core got a dependency on libsystemd recently too, for instance,
fortunately it's only on the at-spi2-core package which we don't use
yet)

Samuel

Samuel Thibault <sthibault@debian.org> (2026-04-14):

Are we expecting those packages to perform this “no systemd is not
running” query and fall back to non-systemd implementation gracefully?


Cheers,

Cyril Brulebois, le mar. 14 avril 2026 11:52:09 +0200, a ecrit:

I expect so, yes.

Samuel