Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1289385 > unrolled thread

Bug#1133417: Provide libsystemd udeb for util-linux

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1133417: Provide libsystemd udeb for util-linux Chris Hofstädtler <zeha@debian.org> - 2026-04-13 11:10 +0200
    Bug#1133417: Provide libsystemd udeb for util-linux Chris Hofstaedtler <zeha@debian.org> - 2026-04-13 16:50 +0200
    Bug#1133417: Provide libsystemd udeb for util-linux Cyril Brulebois <kibi@debian.org> - 2026-04-14 10:30 +0200
      Bug#1133417: Provide libsystemd udeb for util-linux Samuel Thibault <sthibault@debian.org> - 2026-04-14 11:20 +0200
        Bug#1133417: Provide libsystemd udeb for util-linux Cyril Brulebois <kibi@debian.org> - 2026-04-14 12:00 +0200
          Bug#1133417: Provide libsystemd udeb for util-linux Samuel Thibault <sthibault@debian.org> - 2026-04-14 13:10 +0200

#1289385 — Bug#1133417: Provide libsystemd udeb for util-linux

Source: systemd
Severity: normal
Tags: d-i
X-Debbugs-Cc: debian-boot@lists.debian.org

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.

[toc] | [next] | [standalone]

#1289407

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?

> 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.

Chris

[toc] | [prev] | [next] | [standalone]

#1289519

[Multipart message — attachments visible in raw view] — view raw

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):
> 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 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,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#1289524

Hello,

Cyril Brulebois, le mar. 14 avril 2026 10:20:08 +0200, a ecrit:
> Chris Hofstädtler <zeha@debian.org> (2026-04-13):
> > Please provide a libsystemd udeb so libmount (and possibly other
> > things in the future) can use libsystemd.
> 
> 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?

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

[toc] | [prev] | [next] | [standalone]

#1289533

[Multipart message — attachments visible in raw view] — view raw

Samuel Thibault <sthibault@debian.org> (2026-04-14):
> Cyril Brulebois, le mar. 14 avril 2026 10:20:08 +0200, a ecrit:
> > Chris Hofstädtler <zeha@debian.org> (2026-04-13):
> > > Please provide a libsystemd udeb so libmount (and possibly other
> > > things in the future) can use libsystemd.
> > 
> > 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?
> 
> 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)

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 (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#1289541

Cyril Brulebois, le mar. 14 avril 2026 11:52:09 +0200, a ecrit:
> Samuel Thibault <sthibault@debian.org> (2026-04-14):
> > Cyril Brulebois, le mar. 14 avril 2026 10:20:08 +0200, a ecrit:
> > > Chris Hofstädtler <zeha@debian.org> (2026-04-13):
> > > > Please provide a libsystemd udeb so libmount (and possibly other
> > > > things in the future) can use libsystemd.
> > > 
> > > 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?
> > 
> > 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)
> 
> Are we expecting those packages to perform this “no systemd is not
> running” query and fall back to non-systemd implementation gracefully?

I expect so, yes.

Samuel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web