On Tue, 2019-04-09 at 14:20 -0400, Neal Gompa wrote: > On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson > <adamw...@fedoraproject.org> wrote: > > 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. > > > > I'd personally like to see some kind of post-install mechanism that > could remove unneeded things This is on the technical level doable as long as: - RPM & DNF tooling on the image works - you are only removing stuff - the "recipe" what to remove needs to be maintained somewhere and kept current
> or apply updates before rebooting into > the new environment. This on the other hand is a bit harder four a couple reasons: - the current live installation does not need networking and this network is (IIRC) generally not setup, so you would need to make sure network is available at the time you attempt to do this - unlike the live image that is always the same and passes quite some testing (both automated and manual) before it is declared fit for GA, update repos can change more or less at random, creating a miriad of combinations with the live image package set, some of them potentially wrong (file conflicts, broken deps, failing scriptlets) - any errors due to updates might be harder to debug in the live environment than on installed system - note that thisa is not the same as netins as you would be always taking a frozen package set and then aplying a bunch of ever changing updates on top of it VS installing a full system from latest packages on netinst - while making the system up to date (and potentially more secure) this could make the live installation run quite a bit longer & taking ever longer the older the live image is (current live image just rsyncs the base filesystem content to the target, no need to run all the scriptlets and rpm machinery) > That's something that Ubiquity, DrakX, Calamares, > and YaST all do, and it's quite nice to have... It's all possible in principle, but both remove & update is: - extra code not useed on netinst that needs to be written, maintained & QAed - will this be the same for all lives or different per spins vs workstation - do the SIGs taking care of the Workstation live and other live spins actually want this ? > > > > > 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@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 _______________________________________________ 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
