On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote: > > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering <mzerqung@xxxxxxxxxxx> > > 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. > I'd personally like to see some kind of post-install mechanism that could remove unneeded things or apply updates before rebooting into the new environment. That's something that Ubiquity, DrakX, Calamares, and YaST all do, and it's quite nice to have... > > > > > 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). > 'chrony' isn't a cron job thing. That's 'cron' and 'anacron'. 'chrony' is a time server thing, and we should keep that. :) -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
