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-part... 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.