refactor: start using module.yml for module metadata (#116)

* feat: add initial module.yml for rpm-ostree

* chore: add shortdesc to module.yml

* feat: add missing module.ymls

* feat: add website rebuild action for module reference updates

* chore: remove old readme in modules dir

* refactor: switch to a hybrid module.yml + README arrangement

* chore: switch docs to use starlight aside syntax
This commit is contained in:
xyny 2024-02-04 16:05:22 +00:00 committed by GitHub
parent 3914df391f
commit 5e455a1477
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
25 changed files with 227 additions and 242 deletions

View file

@ -1,8 +1,8 @@
# `default-flatpaks` module for startingpoint
# `default-flatpaks`
The `default-flatpaks` module can be used to install or uninstall flatpaks from a configurable remote on every boot. It skips that operation if no changes are detected. This module first removes the Fedora Flatpaks remote and Flatpaks that come pre-installed in Fedora. A Flatpak remote is configured the first time the module is used, but it can be re-configured in subsequent usages of the module. If no Flatpak remote is specified, the module will default to using Flathub.
The `default-flatpaks` module can be used to install or uninstall Flatpaks from a configurable remote on every boot. It skips that operation if no changes are detected. This module first removes the Fedora Flatpaks remote and Flatpaks that come pre-installed in Fedora. A Flatpak remote is configured the first time the module is used, but it can be re-configured in subsequent usages of the module. If no Flatpak remote is specified, the module will default to using Flathub.
Flatpaks can either be installed system-wide or per-user, though per-user flatpaks will be installed for every user on a system. Previously-installed flatpaks can also be removed.
Flatpaks can either be installed system-wide or per-user. Per-user Flatpaks will be installed separetly for every user on a system. Previously-installed flatpaks can also be removed.
The module uses the following scripts to handle flatpak setup:
@ -14,47 +14,8 @@ The scripts are run on every boot by these services:
- `/usr/lib/systemd/system/system-flatpak-setup.service`
- `/usr/lib/systemd/user/user-flatpak-setup-service`
`system-flatpak-setup` uninstalls Fedora flatpaks, replaces Fedora repos with your repo choice, checks the flatpak install/remove lists created by the module & performs the install/uninstall operation according to that. `user-flatpak-setup` functions the same for user flatpaks.
`system-flatpak-setup` uninstalls Fedora flatpaks, replaces Fedora repos with your repo choice, checks the Flatpak install/remove lists created by the module & performs the install/uninstall operation according to that. `user-flatpak-setup` does the same things for user Flatpaks.
This module stores the Flatpak remote configuration and Flatpak install/remove lists in `/etc/flatpak/`. There are two subdirectories, `user` and `system` corresponding with the install level of the Flatpaks and repositories. Each directory has text files containing the IDs of flatpaks to `install` and `remove`, plus a `repo-info.yml` containing the details of the Flatpak repository.
This module also supports disabling & enabling notifications.
## Example configurations
```yaml
type: default-flatpaks
notify: true # Send notification after install/uninstall is finished (true/false)
system:
# If no repo information is specified, Flathub will be used by default
repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
repo-name: flathub
repo-title: "Flathub (system-wide)" # Optional; this sets the remote's user-facing name in graphical frontends like GNOME Software
install:
- org.gnome.Loupe
- one.ablaze.floorp//lightning # This is an example of flatpak which has multiple branches in selection (flatpak//branch).
# Flatpak runtimes are not supported (like org.winehq.Wine//stable-23.08).
# Only normal flatpak applications are (like Floorp Lightning web browser in this example).
# Multiple install of same flatpaks with different branches is not supported.
remove:
- org.gnome.eog
# A flatpak repo can also be added without having to install flatpaks,
# as long as one of the repo- fields is present
user:
repo-name: flathub
```
```yaml
# Assuming that the above example is called first in a recipe,
# a subsequent usage might look like this:
type: default-flatpaks
system:
# If the repo-* fields are omitted, the configured repo will
# use the previous configuration. Otherwise, it defaults to Flathub.
install:
- org.kde.kdenlive
user:
# repo-name will overwrite the previously-configured repo-name for the user remote
repo-name: flathub-user
repo-title: "Flathub (User)
```
This module also supports disabling & enabling notifications.

View file

@ -0,0 +1,38 @@
name: default-flatpaks
shortdesc: The default-flatpaks module can be used to install or uninstall flatpaks from a configurable remote on every boot.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/default-flatpaks/README.md
example: |
modules: # configured multiple times to highlight how options are overridden
- type: default-flatpaks
notify: true # Send notification after install/uninstall is finished (true/false)
system:
# If no repo information is specified, Flathub will be used by default
repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
repo-name: flathub
repo-title: "Flathub (system-wide)" # Optional; this sets the remote's user-facing name in graphical frontends like GNOME Software
install:
- org.gnome.Loupe
- one.ablaze.floorp//lightning # This is an example of flatpak which has multiple branches in selection (flatpak//branch).
# Flatpak runtimes are not supported (like org.winehq.Wine//stable-23.08).
# Only normal flatpak applications are (like Floorp Lightning web browser in this example).
# Multiple install of same flatpaks with different branches is not supported.
remove:
- org.gnome.eog
# A flatpak repo can also be added without having to install flatpaks,
# as long as one of the repo- fields is present
user:
repo-name: flathub
# Assuming that the above example is configured first in a recipe,
# a subsequent usage might look like this:
- type: default-flatpaks
system:
# If the repo-* fields are omitted on the subsequent usage,
# the module will use the previously configured repo.
# Otherwise, it will overwrite the repo configuration.
install:
- org.kde.kdenlive # this Flatpak is appended to the insta llist
user:
# repo-name will overwrite the previously-configured repo-name for the user remote
repo-name: flathub-user
repo-title: "Flathub (User)