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. ;)
- Added missing apps. The list is now synced with upstream's list of Core apps (https://apps.gnome.org/). Minus the few that Fedora doesn't ship by default (such as Console, Music, Web, etc).
- Names that are already installed at the native system-level (such as Nautilus) are not included in the list.
- Fixed the names of a few apps.
- Two of the newly added apps have names that have a high risk of confusing new users, so they were added as "Photos (Organizer)" and "Videos (Player)" to avoid confusion from newcomers, otherwise they might think that those checkboxes add some bundled photos or video files.
- The first screen's "Pick some applications to get started" has been replaced with a friendly welcoming message.
- The second screen's difficult-to-understand "WARNING: This will modify your Flatpaks if you are rebasing!" has been replaced with an explanation of what it actually does.
- The application setup screen is now titled "Application Installer", since the previous title sounded too much like a silly rhyme. It's a minor change.
- All Flatpaks now default to system-wide install thanks to the great work of bsherman at https://github.com/ublue-os/yafti/pull/82. This saves tons of disk space for multi-user systems.
- The "system application" category have been split up into GNOME apps and every other system app, so that people on other desktop environments don't get all the GNOME apps.
- Apps that had too vague descriptions have been renamed to their full names, such as "Backup -> Deja Dup Backups".
- All app lists have been sorted alphabetically.
- Non-inclusive language in descriptions has been changed.
- Added SteamTinkerLaunch as a suggestion for the Steam category, which is the best tool for managing Steam game configurations and Proton installations, albeit very advanced since it can do practically anything the gamer needs. :)
The `-d ""` check is false on bash and zsh, but there might be some rare shell out there which treats it as "." or similar, so let's guard against that risk by also verifying that `$HOME` is a non-empty string before we check if it's a directory.
- The old location was conflicting with upstream images (main, nvidia, etc), and was causing the file to be overwritten.
- It was therefore decided that each image should prefix their own justfile names, to avoid clobbering, to easily allow image makers to bundle multiple "modular" justfiles, and to allow end-users to easily include the particular modules they want.
- The name `custom.just` represents a "template name" for this "custom uBlue image", while being neutral enough to use long-term (unlike the alternative name `startingpoint.just`, which doesn't flow nicely).
- All redundant commands that already existed upstream in `ublue-os/main` have been removed, to follow the new "modular inclusion" nature of uBlue's "justfile" organization, which also means that we'll never have to manually update it to match upstream anymore. No more duplicated effort! ;)
- Updated README instructions to mention the new way of including justfiles, until the upstream "just" project has finished their "include" functionality.
- The ".just" suffix is the official upstream suffix for modular justfile inclusions.
- We don't have any files remaining in "./etc/" in this repo.
- We could add a ".gitkeep" file to it, to keep the "empty" directory, but then that file would get automatically merged as a hidden file into the final image, which is silly.
- So let's just document the proper location to place things instead, which is "usr/etc/".
- The Containerfile has also been cleaned up to be a bit easier to follow along what it's doing, such as putting the "copy scripts" step closer to the actual running of the scripts.
