a639f1f64f
* feat: initial draft of default-flatpaks v2 this version just sets up the config file but nothing to read it and install the flatpaks after boot * chore: streamline logging * chore: replace json with yaml as generated config format * feat: set up groundwork for post boot scripts * feat: rename installations -> configurations, initial implementation of post-boot part * fix: put executable files into /usr/libexec/ * fix: improve fedora remote detection and removal * feat: implement notifications for system flatpak setup * chore(default-flatpaks): No need to expose `DISPLAY` for notify-send * chore(default-flatpaks): Update service & add timers to match v1 * chore(default-flatpaks): Copy & enable timers instead of services * chore(default-flatpaks): Fix typo for copying `user-flatpak-setup` timer * chore(default-flatpaks): Copy post-boot files directly instead of placing them in `/usr/share/...` * chore(default-flatpaks): Forgot to remove copying step of post-boot files to `/usr/share/...` * chore: update to be in accordance with cli support for nushell * feat: allow usage of fedora flatpak remote, remove fedora flatpaks and runtimes * feat: refactor schema to support multiple versions of the module * docs: separate docs for separate module versions * fix: copy user-flatpak-setup.timer to correct directory * chore: correctly document default values in schema * fix: better flathub package checking - use API url - check everything before erroring out * feat: warn users when giving this module v1 configuration * fix: prevent addition of http get result into unavailablePackages list * fix: mkdir before cp * chore: fix () semantics problems highlighted by debugger * feat: bluebuild-flatpak-manager CLI * feat: alert user when trying to use module with old configuration * docs: write basic documentation page and rewrite example * fix: attempt to use configFile variable without dollar sign * fix: no such things as .configurations (the file is the array) * fix: ensure no empty list is printed * docs: add a quick note about learning to use the flatpak manager tool * fix(schema): distinquish between versions Co-authored-by: Gerald Pinder <gmpinder@gmail.com> * fix: add noninteractive flag to flatpak install commands * fix: ensure repo to be used is enabled * chore: ignore errors in notify wrapper just in case * chore: add link to announcement * docs: run through languagetool --------- Co-authored-by: fiftydinar <65243233+fiftydinar@users.noreply.github.com> Co-authored-by: Gerald Pinder <gmpinder@gmail.com> |
||
|---|---|---|
| .. | ||
| post-boot | ||
| default-flatpaks.nu | ||
| README.md | ||
default-flatpaks
:::note For instructions on migration from v1 to v2, see the announcement blog post. :::
The default-flatpaks module can be used to install Flatpaks from a configurable remote on every boot. By default the module will remove the Fedora Flatpak remote and install the Flathub remote, but you can also configure it to install other Flatpaks from other remotes.
Features
- System and user systemd services that are based on your configuration
- Set up a Flatpak remote
- Install Flatpaks from the remote
- CLI tool
bluebuild-flatpak-managerto- Display the Flatpak configurations in the image
- Manually initiate the setup of Flatpaks
- Disable the automatic Flatpak setup
- Re-enable the automatic Flatpak setup
- run the
bluebuild-flatpak-managercommand for help and documentation
Configuration
The default-flatpaks module configuration is based on a list of configurations: that each set a scope to install in (system or user), a Flatpak repository to set up, and a list of Flatpaks to install from the repository.
Multiple configurations are supported, and subsequent module calls will append new configurations to the list. Overriding previous configurations is currently not supported.
Scope
The scope: property can be set to system or user. If omitted, the default is user. This property determines whether the Flatpak repository and packages are set up for the system or for each user separately.
For a single-user system, you can safely use the user scope, since that will allow installation of Flatpaks from the configured repo and management of the installed Flatpaks without authentication. If you have multiple users for whom you want to set up the same system Flatpaks, you should use the system scope. This ensures that the Flatpaks are not duplicated in each user's home directory, and that managing the Flatpaks requires admin permissions.
Flatpak repository
The repo: property is used to configure the Flatpak repository to set up. If omitted, Flathub will be used by default. The URL should be a link to a .flatpakrepo file. The name and title are used to identify the repository in the Flatpak CLI; the name should be lowercase and not contain spaces, while the title can be any string.
Notification
The notify: property can be set to true or false. If omitted, the default is true. This will send a notification on each boot to the user(s) when starting the Flatpak installation and when it is finished.
Flatpak installation
The install: property is a list of the Flatpak IDs to install from the configured repository. If omitted, no Flatpaks will be installed, but the Flatpak repository will still be set up. If the repository to use is configured as Flathub, the list of Flatpaks will be validated at build time to ensure that the packages are available on Flathub.