On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote: > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering <mzerq...@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.
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. > > > 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. 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 notable). > > 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. Boxes is a key component of Workstation, and it relies on libvirt. It's in the 'Core Applications' definition of the Workstation tech spec: https://fedoraproject.org/wiki/Workstation/Technical_Specification#Core_Applications -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
