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.
