Debian Bug report logs - #986651
systemd: stop depending on systemd-timesyncd

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: systemd: stop depending on systemd-timesyncd

Date: Thu, 8 Apr 2021 22:24:58 +0200

Package: systemd
Version: 247.3-3
Tags: bookworm sid

systemd used to include systemd-timesyncd. Now it is split out to a
separate binary package. Thanks. However, systemd now depends on
systemd-timesyncd, so we cannot really remove it (unless installing
something like ntp). For containers, having a time-daemon is not useful
and we want to reduce the filesystem as much as possible. Therefore it
would be good to reduce the dependency to Recommends.

Michael pointed out however that doing so would break installing
systemd-timesyncd by default as debootstrap does not honour Recommends.
It does however use the Priority and a default debootstrap will include
Priority: important packages.

So how about demoting the dependency to Recommends while simultaneously
bumping systemd-timesyncd's Priority to important?

Of course this can only implemented post bullseye, because that is the
first release to ship a systemd-timesyncd separate at all. Demoting it
now would risk loosing it in upgrades. Besides that, the change would be
inappropriate to the freeze policy.

Helmut

Message #12 received at 986651@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Helmut Grohne <helmut@subdivi.de>, 986651@bugs.debian.org

Subject: Re: Bug#986651: systemd: stop depending on systemd-timesyncd

Date: Sat, 10 Apr 2021 12:17:24 +0200

[Message part 1 (text/plain, inline)]

Am 08.04.21 um 22:24 schrieb Helmut Grohne:
> Package: systemd
> Version: 247.3-3
> Tags: bookworm sid
> 
> systemd used to include systemd-timesyncd. Now it is split out to a
> separate binary package. Thanks. However, systemd now depends on
> systemd-timesyncd, so we cannot really remove it (unless installing
> something like ntp). For containers, having a time-daemon is not useful
> and we want to reduce the filesystem as much as possible. Therefore it
> would be good to reduce the dependency to Recommends.

A few thoughts.
The disk footprint of systemd-timesyncd is rather small.
It would be good to know which kind of containers your have in mind.
docker-style (minimal) without an init or with a full-blown init like 
lxc (fat)?
The former doesn't have init/systemd installed (and thus no 
systemd-timesyncd), the latter does and systemd itself is much bigger 
disk footprint wise.

If we bump the prio of systemd-timesyncd, those minimal containers will 
now suddenly get systemd-timesyncd by default (which in turn pulls 
systemd). So this would be a regression. You'd have to be careful to 
omit systemd-timesyncd when building the container image.

For fat containers, having systemd-timesyncd installed doesn't really 
gain you a lot (and is no regression compared to buster, where it was 
folded in). Runtime-wise, having systemd-timesyncd installed, is not a 
problem either, as systemd-timesyncd.service has 
ConditionVirtualization=!container


Michael

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #17 received at 986651@bugs.debian.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>

To: Michael Biebl <biebl@debian.org>

Cc: 986651@bugs.debian.org

Subject: Re: Bug#986651: systemd: stop depending on systemd-timesyncd

Date: Sat, 10 Apr 2021 17:11:39 +0200

Hi Michael,

On Sat, Apr 10, 2021 at 12:17:24PM +0200, Michael Biebl wrote:
> A few thoughts.
> The disk footprint of systemd-timesyncd is rather small.
> It would be good to know which kind of containers your have in mind.
> docker-style (minimal) without an init or with a full-blown init like lxc
> (fat)?

Indeed, I have systemd-nspawn containers in mind. Those require
systemd-container inside the container.

> The former doesn't have init/systemd installed (and thus no
> systemd-timesyncd), the latter does and systemd itself is much bigger disk
> footprint wise.

Indeed, systemd is much bigger, but at the same time, it is much harder
to get rid of. I'm trying to reduce the footprint on all ends.

> If we bump the prio of systemd-timesyncd, those minimal containers will now
> suddenly get systemd-timesyncd by default (which in turn pulls systemd). So
> this would be a regression. You'd have to be careful to omit
> systemd-timesyncd when building the container image.

I don't think minimal containers install Priority: important packages,
not even Priority: required ones.  At least that's not how I approach
it. I usually start with just Essential: yes and add what is needed.
Possibly though, this workflow is not the one other people use. How do
we find out? For instance, e2fsprogs is not Essential: yes, but
Priority: required precisely for the container use case.

In any case, there is no regression as systemd presently is Priority:
important and systemd depends on systemd-timesyncd. If they'd install
systemd-timesyncd due to Priority: important, they'd do it today
already.

> For fat containers, having systemd-timesyncd installed doesn't really gain
> you a lot (and is no regression compared to buster, where it was folded in).

There certainly is a trade-off here. You likely know that I'm also
trimming essential in various aspects. There is no single big thing to
make containers smaller, so what remains is more like 100 paper cuts
that makes them fat. I don't think we can compete with alpine, but we
can get a lot closer. Given how central systemd is today, I think fairly
many practical instances would benefit from being slightly smaller and
at that scale it adds up.

> Runtime-wise, having systemd-timesyncd installed, is not a problem either,
> as systemd-timesyncd.service has ConditionVirtualization=!container

Agreed.

There are magic boundaries at 64MB and 128MB size. For various use
cases, we're slightly above or below these. Debian tends to grow over
time, so it really is work to keep it small.

Helmut

Message #22 received at 986651@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Helmut Grohne <helmut@subdivi.de>, 986651@bugs.debian.org

Subject: Re: Bug#986651: systemd: stop depending on systemd-timesyncd

Date: Sat, 10 Apr 2021 19:17:50 +0200

[Message part 1 (text/plain, inline)]

Am 10.04.2021 um 17:11 schrieb Helmut Grohne:
> On Sat, Apr 10, 2021 at 12:17:24PM +0200, Michael Biebl wrote:

>> If we bump the prio of systemd-timesyncd, those minimal containers will now
>> suddenly get systemd-timesyncd by default (which in turn pulls systemd). So
>> this would be a regression. You'd have to be careful to omit
>> systemd-timesyncd when building the container image.
> 
> I don't think minimal containers install Priority: important packages,
> not even Priority: required ones.  At least that's not how I approach
> it. I usually start with just Essential: yes and add what is needed.
> Possibly though, this workflow is not the one other people use. How do
> we find out? 

Good question.

For instance, e2fsprogs is not Essential: yes, but
> Priority: required precisely for the container use case.
> 
> In any case, there is no regression as systemd presently is Priority:
> important and systemd depends on systemd-timesyncd. If they'd install
> systemd-timesyncd due to Priority: important, they'd do it today
> already.

That's a valid remark, thanks.

My main objective is, that I want to have an NTP client installed in all 
but unusual/special installations.
Demoting the dependency to Recommends would not work afaiu as systemd is 
installed during the initial debootstrap phase where, I was told, 
Recommends are not considered. That's the motivation for the Depends.


If we can achieve the same with Recommends + Prio: important, then I'm 
ok with this change.

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #25 received at 986651-submitter@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <noreply@salsa.debian.org>

To: 986651-submitter@bugs.debian.org

Subject: Bug#986651 marked as pending in systemd

Date: Wed, 22 Sep 2021 22:10:03 +0000

Control: tag -1 pending

Hello,

Bug #986651 in systemd reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/systemd-team/systemd/-/commit/287ced37e2f0f4de2a0e44f850105a1a17ffb815

------------------------------------------------------------------------
Demote systemd-timesyncd from Depends to Recommends

This avoids a dependency cycle between systemd and systemd-timesyncd and
thus makes dist upgrades more predictable and robust.
It also allows minimal, systemd based containers where no NTP client is
strictly necessary.
To ensure that systemd-timesyncd is installed in a default installation
created by d-i, bump its priority to standard.

Closes: #986651
Closes: #993947
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/986651

Message #32 received at 986651-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 986651-close@bugs.debian.org

Subject: Bug#986651: fixed in systemd 247.9-2

Date: Wed, 22 Sep 2021 22:21:43 +0000

Source: systemd
Source-Version: 247.9-2
Done: Michael Biebl <biebl@debian.org>

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 986651@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Biebl <biebl@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 22 Sep 2021 21:10:53 +0200
Source: systemd
Architecture: source
Version: 247.9-2
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Michael Biebl <biebl@debian.org>
Closes: 986651 993947
Changes:
 systemd (247.9-2) unstable; urgency=medium
 .
   * Demote systemd-timesyncd from Depends to Recommends.
     This avoids a dependency cycle between systemd and systemd-timesyncd and
     thus makes dist upgrades more predictable and robust.
     It also allows minimal, systemd based containers where no NTP client is
     strictly necessary.
     To ensure that systemd-timesyncd is installed in a default installation
     created by d-i, bump its priority to standard. (Closes: #986651, #993947)
Checksums-Sha1:
 ebea440451d669054e931c695db65e643b361b26 5167 systemd_247.9-2.dsc
 396895395736b7bea04402dd81ff3e867dc02fa0 163332 systemd_247.9-2.debian.tar.xz
 a2f2d23d779f2f8273fd5a77d3fc495e67e34514 9319 systemd_247.9-2_source.buildinfo
Checksums-Sha256:
 979e55f67c9c34a115bf3772ab455d72cf9b031d9017d364adf58357c84f744d 5167 systemd_247.9-2.dsc
 6a6f0c8a27a0a05cdac6bf393740e21d41f7c680fbfd5b1f532aae1643f9a5b5 163332 systemd_247.9-2.debian.tar.xz
 037999202f2ecaaa210b49462c4de4d218546c543740fcb979347d1ee9410a71 9319 systemd_247.9-2_source.buildinfo
Files:
 2d22948f93c26c77a0fb546096280253 5167 admin optional systemd_247.9-2.dsc
 5832db3558c461b38dcb4ac68b0fc31b 163332 admin optional systemd_247.9-2.debian.tar.xz
 2341a34bb8c2c685a252af0d17f53cec 9319 admin optional systemd_247.9-2_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmFLqXMACgkQauHfDWCP
Itw3UA/+P90O5UIJ5rkopNna4AmydW4lykU8S8udLRukkwtJ81WSJEPa6X6RM7sZ
Gl09hyn0W1/UpQ4UZbCULZyJXwVJGdvFGzgjc6zICrH7InkwndX6unXxd4rCyVwi
FJM+aYW3pGLkUAIojPzJRjkjN/nR3NLLl8a4wnF9GBoZhxH6qyK0eCZzTWM6hTiL
hOGhgN94WEL8sylrS1rR9T2R/x18io+EvbiTxC5ziPa5fnQ6LQVg8MdNjicyCIAk
LWsNPhdrUhoOHFAnQTl1NSdX6SnICuhhreU8z4RT0xkZuzEjqcGdu+49aGq23gpf
hzDJ+1fv4ngfLkd1k6rKLJXYs3Rckh5wj8TvKSrTZB06yCFBNMpt1JiaPrCNS9lk
p83TBswZgMjmv+vPmngOjHC53f0FRP7w41WgXtNx8cJyOQ/7ovklP0vifRTh5YkX
NE08RmGzS3O272ne3hn/MhD+mSB+oDQP9ZxFA3VTp2kYynijrno137kEsL9wa2Hq
cnYtJ9sFClZ0YdKcyaAWqJoCrPcWlHKYaQeDyEnB+M3zj4SqYFd8vT6UdnbFb8Ef
Y6zPA2hY26u25k+Qk/XtT6OrXpHMjMyg7orylxfxBUR9dVnARBNcurcNRt0ig/RC
VeaO79+3n0Yc3lu8n4pbcrTRWR6IwpYIVqVXHzN2nHy6ROuJkSc=
=iDHh
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.