Can we maybe reduce the set of packages we install by default a bit?


today I installed the current Fedora 30 Workstation beta on my new
laptop. It was a bumpy ride, I must say (the partitioner (blivet?)
crashed five times or so on me, always kicking me out of anaconda
again, just because I wanted to undo something). But I don't really
want to discuss that. What I do want to discuss is this:

Can we maybe reduce the default set of packages a bit? In particular
the following ones I really don't think should be in our default

1. multipathd. On a workstation, uh?? I obviously have no multipath
devices configured on my laptop, how would I even? Has anyone? This
is a really nasty one: to this day it pulls in udev settle, which
is really backwards, and slows down our boot considerably. No
current daemon should require udev settle, any daemon that still
does is just backwards because it assumes that hardware would
guarantee to have shown up at some specific time at boot, though in
today's world that's really not how this works: hardware can take
any time it wants, and thus instead of "waiting for everything" you
can reasonably just wait for the stuff you know you actually need,
based on your configuration. systemd-udev-settle.service however is
a compat kludge that is supposed to provide "wait for everything",
though this is racy and flaky. To say this clearly: anything that
still relied on systemd-udev-settle.service 5y ago was bad, but
still pulling that in today in 2019, and doing that in a default
fedora install is just bad bad bad. This alone costs half the boot
time on my system because it just waits for stuff for nothing, and
for what? And beyond that, this daemon is really ugly too: it logs
at high log levels during boot that it found no configuration and
hence nothing to do. Yes, obviously, but that's a reason to shut up
and proceed quickly, not to complain loudly about that so that it
even appears on the scren (I mean srsly, this is the first thing I
saw when i booted from the fedora live media: a log message printed
all over the screen that multipathd has no working

2. dmraid. Not quite as bad as multipathd as it is more likely to
exist on a workstation (still quite exotic though), but also pulls
in udev settle and hence should not be in our default boot. Much
like multipathd this should be fixed to not require udev settle
anymore, and in the absence of that at least not end up in the
default fedora boot process, except for those people who actually
have dmraid.

3. atd? Do we still need that? Do we have postinst scripts that need
this? If so, wouldn't systemd-run be a better approach for those?
Isn't it time to make this an RPM people install if they want it?

4. Similar crond. On my fresh install it's only used by "zfs-fuse",
which I really wonder why it even is in the default install? And
"mdadm" wants this too. (which would be great if it would just use
timer units)

5. libvirtd. Why is this running? Can't we make this socket
activatable + exit-on-idel? While I am sure it's useful on
workstations why run it all the time, given that only very few
users probably actually need that, and if they do starting it on
demand would be much more appropriate? On my freshly installed
system it is running all the time even though there are no VMs or
anything around.

Ideally, the top 4 wouldn't be installed at all anymore (in case of
the first two at least on the systems which do not need them). But if
that's not in the cards, it would be great to at least not enable
these services anymore in the default boot so that they are only a
"systemctl enable" away for people who need them?

I wonder the first one is rooted in a misconception about systemd's
unit condition concept: conditions are extremely lightwight: they just
bypass service start-up, that's all. They have no effect on whether
dependencies are pulled in before hand or not, and they are only
tested the instant the service is ready to be fork()ed off. This means
multipathd.service (which has
ConditionPathExists=/etc/multipathd.conf) pulls in
systemd-udev-settle.service regardless if the condition holds or

I guess I should file bz issues about all of the above, but I am not
sure against which packages? anaconda? comps (does that still exist)?
the individual packages?

It's also my hope that maybe some champion volunteers for tracking
down issues like this and fixing them? i.e. keeping udev settle out of
the default install alone would be a worthy goal for every release,
given that it doubles boot time on typical systems... Anyone up for



Re: Can we maybe reduce the set of packages we install by defaul

By Zbigniew =?utf-... at 04/09/2019 - 13:09

On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote:
This was supposed to be fixed <a href="" title=""></a>.
If not, please reopen that bug.

This was supposed to happen. See
<a href="" title=""></a>.

Individual packages. Logging issue obviously belong in the packages.
In principle fedora-release gets to decide what is started by default,
but it's probably better to start with a bug on the package because
its the maintainers know best if not starting the service by default
is possible and can file a fedora-release PR.


Re: Can we maybe reduce the set of packages we install by defaul

By Stephen John Smoogen at 04/09/2019 - 12:54

On Tue, 9 Apr 2019 at 12:07, Lennart Poettering < ... at 0pointer dot de>

I think the main reason they stick around is that the people who want them
gone just show up right after a release, drop a bunch of requests, and then
go off to their own busy work. Then they come back a release later, don't
see any change and either drop another email detailing things to be dropped
OR discouraged that no-one ever listens. The things that do get changed and
pulled out (or kept in) do so because people come in and work on scrubbing
out the reasons and making sure the replacements are socialized in.

One of the things is that I am not sure any of these items

1. multipathd. On a workstation, uh?? I obviously have no multipath

2. dmraid. Not quite as bad as multipathd as it is more likely to
I think these two are here because of the blivet you mentioned earlier.
Advanced partitioning requires them to be there... and there do seem to be
people who actually do expect both of those to work on their workstations
when it was looked at to be removed in the past.

I do not know if the SIlverBlue does not have them on the other hand.

4. Similar crond. On my fresh install it's only used by "zfs-fuse",
This is more about socializing and teaching the systemd replacements...
because most of the systemd advocates and heavy users I have asked aren't
sure about how systemd replaces them and go back to cron/atd. I actually
think that the replacements seem much better thought out than cruft-ware
but.. but I also have little confidence I could get it to work consistently
while I can find 10k tutorials on cron.

I don't know on this. I remember something about containers and flatpaks
but .. I don't know.

I think it is actually more about what comes up more in the Arch and
serverfault pages on how to set up timed jobs. It has to do with tools to
make it 'one-liners' and 'convert your cruft cron' or 'this will read your
cron and make it cron-d'

As you say below it is about finding champions but those champions have got
to feel comfortable that they can answer things. Those people would then be
the ones to help shepherd this through.

Re: Can we maybe reduce the set of packages we install by defaul

By Adam Williamson at 04/09/2019 - 13:11

On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote:
Basically, anything that's part of the install environment is going to
be present after a live install. That accounts for both of the above:
the installer supports multipath and dmraid storage devices, so the
relevant packages are part of the install environment, so they're part
of the lives, so they're installed by a live install.

This is kind of a limitation of the live deployment mechanism. In
theory a post-install stage could be added to strip things that were
only needed at install time, or that we can tell aren't actually needed
by the installed system, but this has never been done, though I recall
it being discussed at times.

To be specific here, 'at' is part of the @standard group. 'chrony' is
pulled in several ways. It's part of @standard *if gnome-control-center
is being installed*, so effectively it'll be installed with Workstation
but not other editions/spins. That sort of implies that there's some
functionality in GNOME that depends on chrony; I am not sure what that
is, off hand. It's also part of 'anaconda-tools' (so it will be in all
live images and all live installs), part of 'server-product' (so it is
in Server installs), and part of 'system-tools' (so it'll be in
anything that includes that). It's also part of 'workstation-product',
so it's really super *definitely* included in Workstation. :P

I think it is reasonable to suggest that there is a general expectation
that, on an out of the box *nix system, you can put stuff in crontab
and it will work. I like systemd timers, but the system doesn't attempt
cron compatibility so far as I'm aware; if we don't install a cron
daemon, this won't be the case. (I'm actually slightly interested in
whether you wind up with chrony if you do a non-live install of a non-
GNOME desktop; it looks to me like you don't, which is I guess

Boxes is a key component of Workstation, and it relies on libvirt. It's
in the 'Core Applications' definition of the Workstation tech spec:

<a href="" title=""></a>

Re: Can we maybe reduce the set of packages we install by defaul

By Adam Williamson at 04/09/2019 - 13:28

On Tue, 2019-04-09 at 10:11 -0700, Adam Williamson wrote:
nirik points out that I have been sunk by homonyms here: chrony is an
NTP daemon, not a cron daemon. :P

Our 'default' cron daemon is cronie, but that hasn't appeared in comps
at all since it was specifically removed by a PR:

<a href="" title=""></a>

However, I think I know why it's still showing up: 'crontabs' is in
@workstation-product and @standard in comps, and crontabs Recommends