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. ;)
- 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.
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.
