> On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier <siosm(a)fedoraproject.org> > wrote: > Adding network-online.target is not hard, I could do that easily > enough. I would need to change the way the service starts to use a > flag instead of purely relying on firstboot mode though, since I can't > make firstboot run on, well not firstboot if I rely on systemd > firstboot.
It's likely that network-online.target won't be enough on first boot if the network has not been setup in Anaconda and for EOM installations, it won't be as far as I know. I don't remember if GNOME initial setup does it or not. So you'll indeed have to try again multiple times on next boots. But how many times should it retry? If the system is never connected to the internet, should it do that every boot? That's starting to become a lot of logic for a Bash script that runs as root and performs package changes. If not in the initial setup, it could also be added to GNOME Software. In KDE in the welcome app or in Plasma Discover. > Mutating the system is sort of the point? I could just make it a no-op > for Silverblue/Kinoite, but the Workstation WG wanted it universally > applicable, so I did that legwork. We need another solution for Silverblue/Kinoite to setup those libraries post installation without relying on layering. On Silverblue & Kinoite, updates are fast when there are no package layered. If we layer a package on all installations by default, then we just make updates slow for everyone. Note that a lot of users also don't use the browser as installed in the system (we get a lot of complains about that) and install their own instead and thus won't benefit from that change. Existing/upgrading users also won't benefit from it. Using layering will also conflict / not interact well with the move to container based ostree image in F38: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable > Aside from GNOME and KDE Plasma, nobody has an initial setup > interface. We'd have to do this in Anaconda's initial setup wizard. I > would have to build a dedicated application instead, which would > displease everyone. :) This is not the first (and won't be the last) feature that won't have an interface on non GNOME/KDE desktops. We also have https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/ which is set up on first boot in GNOME Initial Setup and thus not setup on KDE desktops right now. Thus I'm not sure that this should be blocking us. --- Overall, I won't oppose adding that for DNF based variants of Fedora if the working groups / desktops spin SIGs are fine with all those constraints. For Silverblue & Kinoite, I think we need another solution. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
