Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 2019-04-09 at 20:20 +0200, Lennart Poettering wrote: > On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) 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. > > Hmm, but the installed OS is not 100% the same as the livesys, or is > it? If not, it should be possible to add a "systemctl disable > dmraid.service --root=/path/to/os" somewhere, no? It's possible, sure. Every bit of post-install tinkering added to anaconda is another thing anaconda has to maintain and that could go wrong or become stale, is the argument against it, I think. But anyone can send a pull request. :P -- 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/9/2019 11:14 AM, Lennart Poettering wrote: On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote: 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. Well, we addresses similar cases by placing README files or so in those directories, so that people might notice if they are looking for something there... i.e. /var/log/README is a similar case and /etc/inittab too. I think we can do the same here too and make clear that people need to install cronie first before these things work. Alternatively. just drop the cron dropin dirs from the base image: if i want to drop in a script in the dirs I should notice if I can't because the dir doesn't actually exist. Is this really worth the effort? cronie in F30 is a 103K package, and a decent chunk of that might be the ChangeLog. crontabs is all of 18K, which is 95% the GPL and the RPM header. It seems like a very small price to pay for something everyone is going to assume will be on any *nix-compatible system of note. The last thing I'd want to have to deal with is solving for a missing /etc/cron.* because someone forgot to click a checkbox somewhere or didn't call it out in kickstart. -jc ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 19:24, Richard Hughes (hughsi...@gmail.com) wrote: > On Tue, 9 Apr 2019 at 19:21, Lennart Poettering wrote: > > Very similar is actually "fwupd", why does that need to run all the > > time? Seems like something that should be bus activatable, and > > exit-on-idle, but why run it all the time? > > It does exit on idle, if you don't have hardware that is tricky to get > version numbers from. If we're polling for the list of firmware > updates once per day we don't want to cause display flicker or that > kind of thing. ThunderBolt and MST are the main offenders here. We're > working on it, but it's not super simple. Hmm? Can you elaborate? Why does fwupd's runtime have something to do with display flickers? Not grokking the connection? Lennart -- Lennart Poettering, Berlin ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 14:16, Cole Robinson (crobi...@redhat.com) wrote: > On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote: > >> multipathd [...] 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 > >>configuration...). > > > > This was supposed to be fixed > > https://bugzilla.redhat.com/show_bug.cgi?id=1631772. > > If not, please reopen that bug. > > > >> 5. libvirtd. Why is this running? Can't we make this socket > >>activatable + exit-on-idel? > > > > This was supposed to happen. See > > https://bugzilla.redhat.com/show_bug.cgi?id=1290357. > > > > This bug (briefly) describes why at present libvirt can't use socket > activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136 Hmm, so that is a valid request I guess. But why can't libvirt do exit-on-idle? i.e. after it started up, after it noticed that it has no VMs to run, checks that there are no IPC requests pending, can't it just exit then and then rely on socket activation to be started again when it is needed the next time? That way libvirt would start at boot, but not stick around during normal runtime. Lennart -- Lennart Poettering, Berlin ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 9 Apr 2019 at 19:21, Lennart Poettering wrote: > Very similar is actually "fwupd", why does that need to run all the > time? Seems like something that should be bus activatable, and > exit-on-idle, but why run it all the time? It does exit on idle, if you don't have hardware that is tricky to get version numbers from. If we're polling for the list of firmware updates once per day we don't want to cause display flicker or that kind of thing. ThunderBolt and MST are the main offenders here. We're working on it, but it's not super simple. Richard. ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 9, 2019 at 1:11 PM Adam Williamson wrote: > > On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote: > > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering > > 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 --
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 10:11, Adam Williamson (adamw...@fedoraproject.org) 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. Hmm, but the installed OS is not 100% the same as the livesys, or is it? If not, it should be possible to add a "systemctl disable dmraid.service --root=/path/to/os" somewhere, no? > To be specific here, 'at' is part of the @standard group. 'chrony' > is Yupp, it's very confusing that we have chrony and cronie in our OS and both are installed by default... ;-) > > 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: Hmm, but boxes supposedly uses the user session version of libvirt, no? it doesn't actually use the system service? I mean, I am even fine if that gets instaleld by default and is listening on a local IPC socket, but why does it have to run all the time? activation by socket and exit-on-idle should be fine too. Very similar is actually "fwupd", why does that need to run all the time? Seems like something that should be bus activatable, and exit-on-idle, but why run it all the time? Lennart -- Lennart Poettering, Berlin ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On 4/9/19 1:09 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote: >> multipathd [...] 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 >>configuration...). > > This was supposed to be fixed > https://bugzilla.redhat.com/show_bug.cgi?id=1631772. > If not, please reopen that bug. > >> 5. libvirtd. Why is this running? Can't we make this socket >>activatable + exit-on-idel? > > This was supposed to happen. See > https://bugzilla.redhat.com/show_bug.cgi?id=1290357. > This bug (briefly) describes why at present libvirt can't use socket activation: https://bugzilla.redhat.com/show_bug.cgi?id=1326136 Libvirtd has a feature to autostart VMs and other resources at host boot up, which is useful and used often that people get mad when it breaks. We need some new work to make this play with socket activation, maybe move the autostart checking to some separate service that runs once at startup. But with a simple implementation Workstation wouldn't benefit because the installed 'default' network is still set to autostart. Thanks, Cole ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 12:54, Stephen John Smoogen (smo...@gmail.com) wrote: > 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. Well, but anaconda makes some changes to the image after copying in the OS, no? it could also do an "systemctl disable mdraid.service --root=/installed/tree" or so if it knows that mdraid is not actually needed... > 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. Well, we addresses similar cases by placing README files or so in those directories, so that people might notice if they are looking for something there... i.e. /var/log/README is a similar case and /etc/inittab too. I think we can do the same here too and make clear that people need to install cronie first before these things work. Alternatively. just drop the cron dropin dirs from the base image: if i want to drop in a script in the dirs I should notice if I can't because the dir doesn't actually exist. Lennart -- Lennart Poettering, Berlin ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Di, 09.04.19 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote: > > multipathd [...] 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 > >configuration...). > > This was supposed to be fixed > https://bugzilla.redhat.com/show_bug.cgi?id=1631772. > If not, please reopen that bug. Appears to be a problem still. Commented there... > > 5. libvirtd. Why is this running? Can't we make this socket > >activatable + exit-on-idel? > > This was supposed to happen. See > https://bugzilla.redhat.com/show_bug.cgi?id=1290357. But it's what I see here. :-( Lennart -- Lennart Poettering, Berlin ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 2019-04-09 at 10:11 -0700, Adam Williamson wrote: > > 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 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: https://pagure.io/fedora-comps/pull-request/179 However, I think I know why it's still showing up: 'crontabs' is in @workstation-product and @standard in comps, and crontabs Recommends cronie. -- 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 2019-04-09 at 12:54 -0400, Stephen John Smoogen wrote: > On Tue, 9 Apr 2019 at 12:07, Lennart Poettering > 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:
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, Apr 09, 2019 at 06:07:09PM +0200, Lennart Poettering wrote: > multipathd [...] 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 >configuration...). This was supposed to be fixed https://bugzilla.redhat.com/show_bug.cgi?id=1631772. If not, please reopen that bug. > 5. libvirtd. Why is this running? Can't we make this socket >activatable + exit-on-idel? This was supposed to happen. See https://bugzilla.redhat.com/show_bug.cgi?id=1290357. > 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? 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. > 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? Zbyszek ___ 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
Re: Can we maybe reduce the set of packages we install by default a bit?
On Tue, 9 Apr 2019 at 12:07, Lennart Poettering 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-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 > -- Stephen J Smoogen. ___ 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
