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

[Helmut Grohne]

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