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.
This implements the new "yafti" launcher and ties everything together:
- The "/etc/profile.d" script is now a symlink to an immutable location, instead of an actual plaintext file, to prevent risk of user systems breaking due to ostree thinking that the script had been modified. We can now be certain that systems always work properly when switching between distros or uBlue flavors.
- Yafti is only installed if the "yafti" flag is enabled.
- If the user disables the "yafti" flag, we completely wipe out the entire yafti.yml configuration, all of our new "yafti autostart" components, and the "profile.d" symlink, so that nothing remains on the system image. If an upstream image installed yafti itself in `/usr/bin`, then we leave that component alone though (because "pip uninstall" and the potential errors it might throw seems like a pointless hassle just for a tiny, unused binary).
- Now uses `sh`-style single-bracket `[]` POSIX syntax instead of the truly old-school `test` syntax. Both are equivalent and equally portable. In fact, `man test` explains everything that `[]` can do.
- We now symlink the user's autostart file to the uBlue image's own file, and we do it in a backwards-compatible way which replaces the user's current legacy script file (if any). The previous system dumped a permanent file in the user's home-directory which never updated again after that, which meant that OS updates could never fix or improve the autostart scripts in the future. That's now possible, thanks to being a symlink.
- If the user uninstalls uBlue, or switches to a flavor without `yafti`, then the leftover "autostart" symlink will simply be a minor nuisance that only causes some soft, invisible syslog warnings about the "broken symlink", which is an improvement over the previous system which kept a full `.desktop` file that attempted to run a binary and failed to find it.
Notable changes:
- The icon is no longer dependent on "GNOME Terminal" being installed. Will now work on any desktop environment, not just GNOME. We only see this icon in "GNOME Tweaks: Startup Applications" or similar autostart-managers, which is even better reason to use a generic, always-existing icon for the shortcut.
- Now runs the new "autostart.sh" yafti GUI launcher.
- Tells the OS to not spawn a terminal window when running this shell script.
Instead of having to use a restrictive command-line in a ".desktop" file, we are now able to use scripting to create more advanced launchers, or if someone wants to easily switch yafti to something else.
This hidden file was missed due to ripgrep's default "skip dotfiles" rule. All previous moves have also been re-analyzed with ripgrep again to ensure that nothing else was missed.
Moving most of the inline docs in autorun.sh to scripts/README.md.
This makes the documentation more discoverable and approachable
(no need to read source code).
This commit also removes redundancies from the inline docs,
clears up some phrasing,
and uses more standard formatting and phrasing such as:
- using `` instead of ""
- calling itself `autorun.sh`
- calling pre and post "execution phases"
This new functionality now makes it possible to execute scripts at the start or end of the build process, while also being super simple to expand to add further script stages in the future.
It also supports effortless reuse of scripts for multiple stages, since the scripts are now executed with the "current stage" as their 1st argument, to allow them to easily determine which stage they're running in.
This fixes the issue where someone specifies `fedora-version: latest`, which won't be known until build-time.
I also added a small "welcome" banner to the build log. It's really just there to retain a somewhat contrived use-case example for how to use `get_yaml_string()`, for other programmers who want to extend this in the future.
You can now define your custom repos with the `%FEDORA_VERSION%` variable, to automatically use the correct repo version, so that you never have to maintain their custom URLs again in the future.
You can now easily remove RPMs from your custom image, without having to edit the build.sh script.
This also changes the old "rpms" config key, to "rpm-install", for consistency with the new setting.
Thanks to leveraging Bash arrays, we are now able to use parameter expansion to perform every package installation as one rpm-ostree operation instead of individual ones. This will give us a huge build speedup.
Bash properly expands every array element as safely quoted arguments, complete with support for spaces and special characters.
This new technique is way easier to use, more maintainable, and safely handles special characters and spaces in the YAML data. It will also enable other features, such as the rpm-ostree improvement coming in the next commit.
The function name is `get_yaml_array()` because it literally reads it into a Bash array, by the way. Don't change the function name in the future. We may need other functions to read values into strings, etc.
Lowercase, run-on sentences are a nightmare to expand later, because the lack of sentence structure means you can't just add more lines and have a nice flow anymore.
Let's add some punctuation and grammar.
