This is necessary because the `rpm-ostree install` command lacks any way to exclude "recommended dependency" packages. It installs everything and the kitchen sink.
Therefore, installing something will often pull in a bunch of unwanted dependencies. The best we can do with the current situation is to run the removal after the install, so that users can remove those unwanted components manually and can be sure that they're actually removed.
Every individual RUN, COPY and ADD action creates an extra container layer, so there was plenty of room for improvement in our Containerfile.
This optimization gets rid of 4 useless layers from our final container image, and shrinks the final OCI download size as follows:
- Removing the "mkdir /tmp/scripts" layer. It's not necessary to manually create the target directory for the container copy action.
- Removing the manual "chmod +x" for the scripts, and putting that step inside "build.sh" instead.
- Removing the manual copying of "build.sh", by instead placing it at "scripts/build.sh" so that it's automatically copied together with all the other scripts in one layer instead.
- Removing the separate "chmod +x build.sh && run build script" step by merging it with the "cleanup temp files and then finalize the container" step, so that we don't create a pointless extra filesystem layer just for the build.sh script execution.
These changes also reduce the size of the final image, because we're cleaning up the image in the exact same step that we run the "build.sh". If we didn't combine these steps, we'd still be keeping a useless extra layer with all the /tmp/ and /var/ junk files that were left over after the build.
Most seriously, the "/var/cache" folder contained copies of ALL RPM FILES that build.sh installed via "rpm-ostree install". This meant that we were generating a very big layer with a lot of junk data that shipped in the final image.
Our build now only generates 7 layers (instead of 11), and users will have a much smaller OCI download since we aren't shipping the cached RPM "build leftovers" or temp files via useless extra layers anymore.
- Documents all triggers, since this repository is a starting point for people to learn from.
- Only deploys the branch named "live", which gives people more deliberate control of what gets deployed. Why not name it "main"? Because that complicates things a lot when forking this template to your own repos, since the template's default branch is also (currently) named "main", which would among other things complicate the act of syncing the fork via GitHub's web UI. The name "main" also confuses the user since it doesn't give them any hint that it's the only live-published branch.
- Only automatically builds the branches "live", "template" or "main" when pushing new commits. But builds any branch name when it's a pull request, to allow automated PR "build checks" to succeed.
This is super important. Without these checks, the system can end up in a broken state where certain users or even the system itself lacks the "flathub" remote, which then breaks yafti's ability to install software, and also breaks consistency between multi-user accounts.
Before these fixes, we only installed "flathub" for the current user on multi-user systems, and then never again, since our installation of Flathub was dependent on the removal of Fedora's own repositories, and never happened again after that.
We now sanity-check both the system and the user-account on every yafti run.
If someone doesn't want "flathub" at the user-level, they're welcome to make their own image which removes that check. But as a "starting point" template, we should strive to provide a robust example that the largest amount of people will be happy with, which means ensuring that Flathub exists for all users on the system!
Most people run a single-user system, and will never even see these screens, since they'll see the initial screen which removes Fedora's repos and takes care of adding Flathub at the same time. These "system repair" screens will only be seen by people on multi-user systems or on various messed up systems.
PS: The strange "run" condition is required since yafti demands that the return code of a command should be "0" to show a conditional screen, but "grep" by itself returns "1" when nothing matches. Negation operators such as `!` don't work in the run-conditions either, so this workaround does the job perfectly instead. It robustly checks for the exact number "0", meaning that the Flathub remote wasn't found.
We're now deleting the "fedora" Flatpak repos if they're detected on either the system or user level. All software is crippled in their repos, and less maintained than Flathub, so there's no good reason to have them.
More importantly, we're now also installing the Flathub repo system-wide instead of merely the user-level. This has two important effects:
1. People who opted out of "Third Party Repos" during OS installation will now receive the Flathub repo, to ensure that their system still works properly in that scenario.
2. It gets rid of the "Filter" line in `/var/lib/flatpak/repo/config`, so that Fedora can never reinstate the filtering in the future.
As for why we install Flathub at both the user and system levels: We need both, since the user then gets a nice dropdown menu inside GNOME Software, which lets them switch between system-wide or per-user installation locations.
The "remote" name detection has also been improved, by only printing the raw "name" column, to avoid any risk of false positives.
Having duplicates in the yafti.yml where a package exists in multiple groups *currently* causes subtle bugs in yafti, such as a package becoming deselected even though the entire group is "selected". That causes great confusion when users try to install "Core GNOME Apps" without realizing that they won't receive the Extension Manager (for example), since it existed in a different group too and therefore became automatically unchecked in yafti.
A future yafti update will make all duplicate flatpak names illegal (a yml validation error), so this change also prepares us for that, by removing all duplicates.
As for why I added Krita: Since there was only one unique app in the recipe.yml, I needed another random, popular app to fit the example of "this is a selection of example apps", there's nothing more to it than that. ;)
