F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/AutoFirstBootServices

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Add {{package|fedora-autofirstboot}} to desktop variants to run a
predetermined set of tasks on first boot after post installation,
notably installing codecs and cleaning up installer packages from the
installed system.

== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: [e-mail]

== Detailed Description ==
{{package|fedora-autofirstboot}} is a collection of scripts that
invoke on firstboot of a freshly installed system to run a set of
predetermined tasks. It also provides a framework for third-parties to
introduce their own firstboot tasks to run through this framework. The
initial services included are to install OpenH264 and remove Anaconda.

== Benefit to Fedora ==
The main benefit is to smooth out the new user experience for new
Fedora Linux installations. In particular, we can deal with a
long-standing sticking point that Anaconda remains installed on the
user's machine when it is not useful to do so.

== Scope ==
* Proposal owners:
** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
** Add a preset to {{package|fedora-release}} for
<code>fedora-autofirstboot.service</code>

* Other developers: N/A (not needed for this Change)

* Release engineering: [https://pagure.io/releng/issue/11148 #11148]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
This will have no impact on upgraded systems, since the firstboot
condition is not true in that case.

== How To Test ==

# Install Fedora Workstation, KDE, etc.
# Reboot into installed environment
# Check to see <code>openh264</code> is installed and
<code>anaconda-core</code> is not.

== User Experience ==
The first boot will be slightly slower because of these tasks running,
though they should happily run in the background as other services
start up, so it should not be noticeable.

== Dependencies ==
The main dependency is {{package|fedora-release}}, though we will need
to ensure all {{package|udisks2}} plugins get pulled in as
dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
they don't get uninstalled when Anaconda is.

== Contingency Plan ==
* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
the kickstarts
* Contingency deadline: Final freeze
* Blocks release? No

== Documentation ==
There is not currently much documentation in
[https://pagure.io/fedora-autofirstboot the upstream project], though
contributions are welcome.

== Release Notes ==
Fedora Linux now ships with a framework for setting up first-boot
services and uses this to install multimedia software and remove the
installer software from the system after installation.

[Dan Čermák]

Hi,

On November 23, 2022 8:08:59 PM UTC, Ben Cotton  wrote:
> https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Add {{package|fedora-autofirstboot}} to desktop variants to run a
> predetermined set of tasks on first boot after post installation,
> notably installing codecs and cleaning up installer packages from the
> installed system.
>
> == Owner ==
> Name: [[User:Ngompa| Neal Gompa]]
> Email: [e-mail]
>
> == Detailed Description ==
> {{package|fedora-autofirstboot}} is a collection of scripts that
> invoke on firstboot of a freshly installed system to run a set of
> predetermined tasks. It also provides a framework for third-parties to
> introduce their own firstboot tasks to run through this framework. The
> initial services included are to install OpenH264 and remove Anaconda.
>
> == Benefit to Fedora ==
> The main benefit is to smooth out the new user experience for new
> Fedora Linux installations. In particular, we can deal with a
> long-standing sticking point that Anaconda remains installed on the
> user's machine when it is not useful to do so.
>
> == Scope ==
> Proposal owners:
>
> ** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
> ** Add a preset to {{package|fedora-release}} for
> <code>fedora-autofirstboot.service</code>
>
> Other developers: N/A (not needed for this Change)
>
> Release engineering: [https://pagure.io/releng/issue/11148 #11148]
>
> Policies and guidelines: N/A (not needed for this Change)
>
> Trademark approval: N/A (not needed for this Change)
>
> Alignment with Objectives: N/A
>
> == Upgrade/compatibility impact ==
> This will have no impact on upgraded systems, since the firstboot
> condition is not true in that case.
>
> == How To Test ==
>
> # Install Fedora Workstation, KDE, etc.
> # Reboot into installed environment
> # Check to see <code>openh264</code> is installed and
> <code>anaconda-core</code> is not.
>
> == User Experience ==
> The first boot will be slightly slower because of these tasks running,
> though they should happily run in the background as other services
> start up, so it should not be noticeable.
>
> == Dependencies ==
> The main dependency is {{package|fedora-release}}, though we will need
> to ensure all {{package|udisks2}} plugins get pulled in as
> dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
> they don't get uninstalled when Anaconda is.
>
> == Contingency Plan ==
> Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
>
> the kickstarts
> Contingency deadline: Final freeze
> Blocks release? No
>
> == Documentation ==
> There is not currently much documentation in
> [https://pagure.io/fedora-autofirstboot the upstream project], though
> contributions are welcome.

This sounds great, but it would be nice if the documentation could be expanded, before we flick the switch that makes this the default in Fedora. Especially as this sounds like something that could simplify our (=the i3 SIG) kickstart and custom scripts.
> == Release Notes ==
> Fedora Linux now ships with a framework for setting up first-boot
> services and uses this to install multimedia software and remove the
> installer software from the system after installation.

[Timothée Ravier]

Sorry I'm late here but while I agree with the idea, I don't think the implementation is done at the right level.

As currently implemented, this will likely fail as the network won't be available / ready: https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstb...

This will also mutate rpm-ostree based systems on first boot (Silverblue & Kinoite), losing all the benefits of using a single image for everyone and making the update slower for everyone by default.

I think that this is better implemented in a per-desktop app on first session startup on in the GNOME initial setup interface or corresponding project for other desktops.

Having that done in a user visible interface will also surface errors where in this current implementation, any error will mostly be silently ignored.

[Neal Gompa]

On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier  wrote:
> Sorry I'm late here but while I agree with the idea, I don't think the implementation is done at the right level.
>
> As currently implemented, this will likely fail as the network won't be available / ready: https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstb...

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.
> This will also mutate rpm-ostree based systems on first boot (Silverblue & Kinoite), losing all the benefits of using a single image for everyone and making the update slower for everyone by default.

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.
> I think that this is better implemented in a per-desktop app on first session startup on in the GNOME initial setup interface or corresponding project for other desktops.

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. :)
> Having that done in a user visible interface will also surface errors where in this current implementation, any error will mostly be silently ignored.

That was intentional.

--
真実はいつも一つ！/ Always, there's only one truth!

[Timothée Ravier]

> On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier <siosm(a)fedoraproject.org&gt; 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-r... 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.

[Colin Walters]

On Fri, Dec 9, 2022, at 10:59 AM, Timothée Ravier wrote:
> Using layering will also conflict / not interact well with the move to 
> container based ostree image in F38: 
> https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable

(I'm only kind of following this thread and I agree we should not enable layering by default)

But a note: from the rpm-ostree perspective, we intend to still fully support client side layering.  Obviously this change suddenly makes it very straightforward to do derivative server-side layering/builds, and there's been a lot of excitement around that.  I do expect most even semi-technical users to do this.  But it's not clear to me that we should say that's the *only* path and at a technical level today a lot of work went into keeping that functionality.  For example, today for OpenShift for example we client side package layer kernel-rt and a few other things.  I obviously want us to move to always building an image, but it needs some work.

There's also valid use cases around things like "I want to ssh to this one machine and install kernel-debug".

On Fri, 2022-12-09 at 13:23 +0000, Timothée Ravier wrote:
> Sorry I'm late here but while I agree with the idea, I don't think
> the implementation is done at the right level.
>
> As currently implemented, this will likely fail as the network won't
> be available / ready:
> https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstb...

IIRC that was the issue we hit when we investigated the idea to do
package updates or adding language packs in the target system chroot
after the Live iso base layer has been rsynced to the disk.

There might not be any network conectivity at this point, as the live
image is by default offline capable and thus does not require the user
to setup networking before starting the installation.
> This will also mutate rpm-ostree based systems on first boot
> (Silverblue & Kinoite), losing all the benefits of using a single
> image for everyone and making the update slower for everyone by
> default.
>
> I think that this is better implemented in a per-desktop app on first
> session startup on in the GNOME initial setup interface or
> corresponding project for other desktops.
>
> Having that done in a user visible interface will also surface errors
> where in this current implementation, any error will mostly be
> silently ignored.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

On Wed, 2022-11-23 at 15:08 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if
> approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Add {{package|fedora-autofirstboot}} to desktop variants to run a
> predetermined set of tasks on first boot after post installation,
> notably installing codecs and cleaning up installer packages from the
> installed system.
>
> == Owner ==
> Name: [[User:Ngompa| Neal Gompa]]
> Email: [e-mail]
>
> == Detailed Description ==
> {{package|fedora-autofirstboot}} is a collection of scripts that
> invoke on firstboot of a freshly installed system to run a set of
> predetermined tasks. It also provides a framework for third-parties
> to
> introduce their own firstboot tasks to run through this framework.
> The
> initial services included are to install OpenH264 and remove
> Anaconda.
>
> == Benefit to Fedora ==
> The main benefit is to smooth out the new user experience for new
> Fedora Linux installations. In particular, we can deal with a
> long-standing sticking point that Anaconda remains installed on the
> user's machine when it is not useful to do so.

Aren't some Fedora spins still using Initial Setup (not to be confused
with Gnome Initial Setup) ? That would get it removed as well, if the
anaconda package is uninstaled.

But I guess this new tool could be hooked only after Initial Setup has
finished running during the first boot - by which point it should by
fine to remove Anaconda & Initial Setup from the system.
> == Scope ==
> Proposal owners:
>
> ** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
> ** Add a preset to {{package|fedora-release}} for
> <code>fedora-autofirstboot.service</code>
>
> Other developers: N/A (not needed for this Change)
>
> Release engineering: [https://pagure.io/releng/issue/11148%C2%A0#11148]
>
> Policies and guidelines: N/A (not needed for this Change)
>
> Trademark approval: N/A (not needed for this Change)
>
> Alignment with Objectives: N/A
>
> == Upgrade/compatibility impact ==
> This will have no impact on upgraded systems, since the firstboot
> condition is not true in that case.
>
> == How To Test ==
>
> # Install Fedora Workstation, KDE, etc.
> # Reboot into installed environment
> # Check to see <code>openh264</code> is installed and
> <code>anaconda-core</code> is not.
>
> == User Experience ==
> The first boot will be slightly slower because of these tasks
> running,
> though they should happily run in the background as other services
> start up, so it should not be noticeable.
>
> == Dependencies ==
> The main dependency is {{package|fedora-release}}, though we will
> need
> to ensure all {{package|udisks2}} plugins get pulled in as
> dependencies for {{package|gnome-disks}} and {{package|blivet-gui}}
> so
> they don't get uninstalled when Anaconda is.
>
> == Contingency Plan ==
> Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
>
> the kickstarts
> Contingency deadline: Final freeze
> Blocks release? No
>
> == Documentation ==
> There is not currently much documentation in
> [https://pagure.io/fedora-autofirstboot%C2%A0the upstream project], though
> contributions are welcome.
>
> == Release Notes ==
> Fedora Linux now ships with a framework for setting up first-boot
> services and uses this to install multimedia software and remove the
> installer software from the system after installation.
>
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Neal Gompa]

On Fri, Dec 9, 2022 at 10:46 AM  wrote:
> On Wed, 2022-11-23 at 15:08 -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if
> > approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > Add {{package|fedora-autofirstboot}} to desktop variants to run a
> > predetermined set of tasks on first boot after post installation,
> > notably installing codecs and cleaning up installer packages from the
> > installed system.
> >
> > == Owner ==
> > Name: [[User:Ngompa| Neal Gompa]]
> > Email: [e-mail]
> >
> > == Detailed Description ==
> > {{package|fedora-autofirstboot}} is a collection of scripts that
> > invoke on firstboot of a freshly installed system to run a set of
> > predetermined tasks. It also provides a framework for third-parties
> > to
> > introduce their own firstboot tasks to run through this framework.
> > The
> > initial services included are to install OpenH264 and remove
> > Anaconda.
> >
> > == Benefit to Fedora ==
> > The main benefit is to smooth out the new user experience for new
> > Fedora Linux installations. In particular, we can deal with a
> > long-standing sticking point that Anaconda remains installed on the
> > user's machine when it is not useful to do so.
>
> Aren't some Fedora spins still using Initial Setup (not to be confused
> with Gnome Initial Setup) ? That would get it removed as well, if the
> anaconda package is uninstaled.
>
> But I guess this new tool could be hooked only after Initial Setup has
> finished running during the first boot - by which point it should by
> fine to remove Anaconda & Initial Setup from the system.

We only do it if the firstboot wizard is either g-i-s (GNOME) or
pico-wizard (KDE Plasma), otherwise we do nothing.

[Timothée Ravier]

The main issue with this change for Silverblue/Kinoite is that this introduces client side layering by default for all users.

To understand why this is not a good idea, I need to recap a few things: how rpm-ostree client side layering works, the general goal behind rpm-ostree and image based updates and what we're trying to do in https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable.

First, let's start with rpm-ostree client side layering.

When you update a "pristine" Silverblue system, the following happens:
1. rpm-ostree looks into the remote ostree repo for the latest version commit and downloads all the files needed for it into the local repo.
2. Once this is done, it creates a new deployments, which is a new copy of /usr made mostly of hardlinks to the repo.
3. Then you can reboot and you're done.

When you enable client side layering, because you want to change something in the image, remove a package, add a new one, etc., the following happens:
1. rpm-ostree has to fetch the needed files into the repo like in the previous case (step 1).
2. But then, instead of creating directly creating a new deployment, it creates a temporary one with the content of the latest commit.
3. From this temporary deployment, rpm-ostree is able to fetch all RPM metadata from the Fedora repos, then resolve the dependencies for the added/replaced/removed packages and download the RPMs as needed.
4. It will then create a temporary writable overlay on top of the temporary deployment, perform the package installations, replacements, removals and optionally rebuild the initrd.
5. Then it will process the files in this overlay to create a new ostree commit.
6. Finally, it will deploy this new commit into a new deployment to be used after a reboot.

Given the additional steps required when client side layering is used, updates will take longer to be downloaded, prepared and installed and will require more CPU and memory.

Additionally, any operation done on the temporary deployment may fail: missing dependencies, conflicts, wrong package signatures, etc.

The idea behind rpm-ostree hybrid model is that you don't have to manage package conflicts, installation, etc. on the client side and instead rely on the server composing a working image for you. With client side layering, this guarantee goes away and the user will have to intervene when it fails.

This is the main reason why we recommend to be careful with client side layering: it may fail and you'll have to figure out why, just like you need to figure out dependency resolutions issues on a classic DNF based system.

The main goal of Silverblue is to get rid of this issue in the first place by relying only on images by default. Users may choose to override things in the image but they would have to do that on purpose, via the command line, hopefully knowing that they are now responsible when something fails.

Note that neither GNOME Software nor Plasma Discover support managing client side layered packages right now. GNOME Sofware pre-downloads packages, essentially making the first step invisible to the user and only then notifies the user to trigger the 2nd and 3rd steps. Plasma Discover is not yet capable of doing that but I'm working on it.

So yes, client side layering is fully supported in Silverblue/Kinoite as it enables debugging, testing, workarounds, etc. but we don't want to expose users to it by default as this is not a good user experience.

One solution to reduce the time taken by client side layering and those issues mentioned above is to move the package overrides back to the server side by using a layering approach similar to the one used to build containers. This is the goal of this change: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It enables users to make custom builds of Silverblue/Kinoite with their own selection of packages and changes and then to distribute them as an image to their systems, getting the full benefits of pure image based updates back if they don't do any local changes anymore.

I hope that explained things in more details.

[Michael Catanzaro]

> One solution to reduce the time taken by client side layering and those issues mentioned
> above is to move the package overrides back to the server side by using a layering
> approach similar to the one used to build containers. This is the goal of this change:
> https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It enables users to
> make custom builds of Silverblue/Kinoite with their own selection of packages and changes
> and then to distribute them as an image to their systems, getting the full benefits of
> pure image based updates back if they don't do any local changes anymore.

We can't do that on Fedora infrastructure, though, because we cannot distribute OpenH264. It would have to be done by Cisco. Seems like a no-go.

But it might be OK to just not run fedora-autofirstboot for Silverblue/Kinoite. Thing is, system multimedia codecs are really a lot less important on Silverblue/Kinoite than they are on traditional desktops. What users really care most about is whether their _applications_ can play videos. That's a solved problem for anything using Flathub. For Fedora Flatpaks, the solution would have to be Flatpak extensions hosted by Cisco: overlaying OpenH264 on the host system won't actually accomplish anything useful. Even if you need it for a command line tool like ffmpeg, you're probably using a toolbx container for that, so again it's just not nearly so important on the host system.

[Adam Williamson]

On Thu, 2022-12-15 at 00:11 +0000, Michael Catanzaro via devel wrote:
> For Fedora Flatpaks, the solution would have to be Flatpak extensions
> hosted by Cisco: overlaying OpenH264 on the host system won't
> actually accomplish anything useful. Even if you need it for a
> command line tool like ffmpeg, you're probably using a toolbx
> container for that, so again it's just not nearly so important on the
> host system.

Well, except that we ship Firefox in the default OS image and to make
that play video, overlaying openh264 is *exactly* what's needed.

That sucks, though. It needs fixing somehow. Hopefully not by just
telling people to use the upstream Flathub Firefox, because I
appreciate the work our maintainer does to provide a build with (IMHO)
superior choices.

[Michael Catanzaro]

> On Thu, 2022-12-15 at 00:11 +0000, Michael Catanzaro via devel wrote:
>
> Well, except that we ship Firefox in the default OS image and to make
> that play video, overlaying openh264 is *exactly* what's needed.

Ah, drat... well there's not a lot of great options, then. We can (a) change it to use Fedora Flatpak and convince Cisco to host an extension, or (b) give up on the goal of not having any default overlays, or (c) give up on users being able to watch most videos. Please let's not do (c)?

[Timothée Ravier]

Working on having a better Firefox shipped as a Flatpak by default will please a lot of people that as asking for Firefox to be removed from the base image: https://github.com/fedora-silverblue/issue-tracker/issues/288

If we can have Cisco host a container image with openh264 as a Flatpak extension then that would be great as the extension would be pulled down automatically during flatpak update.

[Neal Gompa]

On Mon, Jan 9, 2023 at 11:57 AM Timothée Ravier  wrote:
> Working on having a better Firefox shipped as a Flatpak by default will please a lot of people that as asking for Firefox to be removed from the base image: https://github.com/fedora-silverblue/issue-tracker/issues/288
>
> If we can have Cisco host a container image with openh264 as a Flatpak extension then that would be great as the extension would be pulled down automatically during flatpak update.

First, we have to build one as an extension to the Fedora Flatpak
runtime (which includes ffmpeg and friends). That hasn't been done
yet, as far as I know.

--
真実はいつも一つ！/ Always, there's only one truth!

[Vitaly Zaitsev]

On 15/12/2022 01:38, Adam Williamson wrote:
> Hopefully not by just
> telling people to use the upstream Flathub Firefox, because I
> appreciate the work our maintainer does to provide a build with (IMHO)
> superior choices.

Flathub's Firefox is the worst Firefox ever on Linux. They are still 
building it with ASLR and hardening disabled and for a limited number of 
architectures.

They also don't use the Flathub's infra for building this package and 
uploading prebuilt ostree blob.

[Vitaly Zaitsev]

On 15/12/2022 01:11, Michael Catanzaro via devel wrote:
> We can't do that on Fedora infrastructure, though, because we cannot distribute OpenH264. It would have to be done by Cisco. Seems like a no-go.

I think instead of creating bash scripts we can simply use a weak 
dependency on plasma-workspace, gnome-shell, etc.

Yes, current Fedora packaging guidelines strictly prohibit such 
behavior, but we can as a FESCo exception for openh264 package.

It will be the best solution, IMO.

[Vitaly Zaitsev]

On 15/12/2022 11:24, Vitaly Zaitsev wrote:
> Yes, current Fedora packaging guidelines strictly prohibit such 
> behavior, but we can as a FESCo exception for openh264 package.

Also, we can update the openh264 package and include all needed reverse 
weak dependencies there:

Supplements: plasma-workspace
Supplements: gnome-shell
Supplements: $any_other_DE_meta_package$

No FESCo exceptions will be required because this package is from a 
third-party Cisco repository.

[Neal Gompa]

On Thu, Dec 15, 2022 at 5:43 AM Vitaly Zaitsev via devel
 wrote:
> On 15/12/2022 11:24, Vitaly Zaitsev wrote:
> > Yes, current Fedora packaging guidelines strictly prohibit such
> > behavior, but we can as a FESCo exception for openh264 package.
>
> Also, we can update the openh264 package and include all needed reverse
> weak dependencies there:
>
> Supplements: plasma-workspace
> Supplements: gnome-shell
> Supplements: $any_other_DE_meta_package$
>
> No FESCo exceptions will be required because this package is from a
> third-party Cisco repository.

Aside from being a pain to maintain, DNF was changed a while ago to
ignore weak relations for already-installed packages on upgrade.
That's why these scripts got written.

[Vitaly Zaitsev]

On 15/12/2022 12:03, Neal Gompa wrote:
> Aside from being a pain to maintain, DNF was changed a while ago to
> ignore weak relations for already-installed packages on upgrade.
> That's why these scripts got written.

Maybe we can change the system-upgrade plugin to bypass such behavior on 
system upgrades?

[Neal Gompa]

On Thu, Dec 15, 2022 at 6:50 AM Vitaly Zaitsev via devel
 wrote:
> On 15/12/2022 12:03, Neal Gompa wrote:
> > Aside from being a pain to maintain, DNF was changed a while ago to
> > ignore weak relations for already-installed packages on upgrade.
> > That's why these scripts got written.
>
> Maybe we can change the system-upgrade plugin to bypass such behavior on
> system upgrades?

And what about new installs? That's where the real problem is.

[Vitaly Zaitsev]

On 15/12/2022 12:53, Neal Gompa wrote:
> And what about new installs? That's where the real problem is.

On new installations, weak dependencies will be installed automatically 
out of the box.

[Neal Gompa]

On Thu, Dec 15, 2022 at 7:27 AM Vitaly Zaitsev via devel
 wrote:
> On 15/12/2022 12:53, Neal Gompa wrote:
> > And what about new installs? That's where the real problem is.
>
> On new installations, weak dependencies will be installed automatically
> out of the box.

That stopped working several releases ago.

[Vitaly Zaitsev]

On 15/12/2022 13:34, Neal Gompa wrote:
> That stopped working several releases ago.

It should be fixed then. Please report this issue to dnf component.

Some suggestions for current implementation:

1. Please rewrite the first run script from Bash to Python. Running bash 
scripts as root is extremely dangerous. One mistake or empty variable 
can cause a disaster.

Example: rm -rf /usr/$foo. If the $foo variable is empty, it will wipe 
the entire /usr. Also everyone can inject any commands and execute them 
as root. Example: $foo = '; curl .... | bash'.

2. Please do a network presence check before doing anything. Most users 
store Wi-Fi passwords in a KDE/GNOME keyring and there is no network 
access during the boot. The script will fail instantly.

3. Please check if the full ffmpeg-libs or libavcodec-freeworld are 
installed. In such configurations, OpenH264 is not needed.

4. Please implement an opt-out switch. Some users don't want openh264 
from Cisco's third-party repository to be installed.

[Neal Gompa]

On Thu, Dec 15, 2022 at 7:51 AM Vitaly Zaitsev via devel
 wrote:
> On 15/12/2022 13:34, Neal Gompa wrote:
> > That stopped working several releases ago.
>
> It should be fixed then. Please report this issue to dnf component.
>
> Some suggestions for current implementation:
> Please rewrite the first run script from Bash to Python. Running bash
>
> scripts as root is extremely dangerous. One mistake or empty variable
> can cause a disaster.
>
> Example: rm -rf /usr/$foo. If the $foo variable is empty, it will wipe
> the entire /usr. Also everyone can inject any commands and execute them
> as root. Example: $foo = '; curl .... | bash'.

I don't take user input, so this doesn't matter, but...
> Please do a network presence check before doing anything. Most users
>
> store Wi-Fi passwords in a KDE/GNOME keyring and there is no network
> access during the boot. The script will fail instantly.

... doing this will require Python anyway.
> Please check if the full ffmpeg-libs or libavcodec-freeworld are
>
> installed. In such configurations, OpenH264 is not needed.

Meh.
> Please implement an opt-out switch. Some users don't want openh264
>
> from Cisco's third-party repository to be installed.

Already exists.

[Michael Catanzaro]

> On 15/12/2022 13:34, Neal Gompa wrote:
>
> It should be fixed then. Please report this issue to dnf component.

Using weak deps was our original plan, but problem is it broke due to https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect and we surely do not want to revert that. Also, it was less robust because it required dummy firefox and totem updates to cause the weak deps to be pulled in, and we regularly forgot to prepare those zero-day updates.
> Please do a network presence check before doing anything. Most users
>
> store Wi-Fi passwords in a KDE/GNOME keyring and there is no network 
> access during the boot. The script will fail instantly.

I agree that the script needs to be robust to the absence of network connectivity on first boot. That can happen for a variety of reasons.
> Please implement an opt-out switch. Some users don't want openh264
>
> from Cisco's third-party repository to be installed.

I don't agree that it needs an opt-out switch. (a) It should not be behind the existing third-party software opt-out switch, because this open source software is built for Fedora, by Fedora, and signed by Fedora. It uses a third-party host purely for legal reasons. (b) Adding a second GUI configuration switch would result in a confusing user experience. (c) It's easy for technical users to uninstall openh264 and disable the repo if desired. (d) You can also do your first boot without internet connected, then disable the systemd service to stop it from running in the first place if you really want it to never get installed.

[Vitaly Zaitsev]

On 23/11/2022 21:08, Ben Cotton wrote:
> Add {{package|fedora-autofirstboot}} to desktop variants to run a
> predetermined set of tasks on first boot after post installation,
> notably installing codecs and cleaning up installer packages from the
> installed system.

I checked the proposed bash scripts and found that they will silently 
fail if there is no network access, which is a common practice on 
laptops with Wi-Fi only connections.