On Mon, 13 Apr 2026 16:39:07 +0200 Chris Hofstaedtler <[email protected]> wrote: > On Mon, Apr 13, 2026 at 10:45:10AM +0100, Luca Boccassi wrote: > > > 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. > > > > 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. > > TTBOMK it runs udev. I don't know the inner workings of udev etc., > but the data is probably there?
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 > > 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. > > 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. 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.
