On Tue, 9 Apr 2019 at 12:07, Lennart Poettering <mzerqung@0pointer.de> wrote:
Heya,

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
install:


This is not the first time this has come up and I expect it won't be the last time.

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.
 

3. atd? Do we still need that? Do we have postinst scripts that need
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.

 

5. libvirtd. Why is this running? Can't we make this socket

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

I wonder the first one is rooted in a misconception about systemd's
unit condition concept: conditions are extremely lightwight: they just

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.
 
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 may actually require a larger change that goes through the release process. It would work better to work with the Workstation and/or Silverblue team to get them to champion it themselves as it does meet what they have said they want.. 

 
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
that?

Lennart
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


--
Stephen J Smoogen.