* chore(default-flatpaks): Switch to standardized BlueBuild location
Use
`/usr/etc/bluebuild/default-flatpaks`
location instead of
`/usr/etc/flatpaks`
If possible, we should ideally use this location for system modifications:
`/usr/share/bluebuild/default-flatpaks`
While having user modifications in:
`/usr/etc/bluebuild/default-flatpaks`
But it needs to be figured out how the logic will work for separating system & user modifications this way.
I used this logic in unofficial `initramfs-setup` module & it works well, by merging both system & user files into 1 output.
However, this method can create duplicates if user specified it in it's modification, so I mentioned that user should look if the system entry has modifications they need. Perhaps, array diff can be done, which would circumvent this.
So merge this for start.
Only other module which has potential for migrating to standardized BlueBuild config is yafti (more details in other PR I'll do in some time).
* refactor(default-flatpaks): Make default-flatpaks more robust
Document in detail to user how he can change the config in files itself.
Also document what files do in `/usr/share/bluebuild/default-flatpaks` as well.
Refactor flatpak lists detection to be more reliable by excluding words starting with # symbols, whitelines & duplicate entries. Use `comm` for comparing flatpak list to existing flatpaks output instead of using `grep`, as it's easier to use & it's more reliable.
Separate user's & maintainer's modifications better by utilizing read-only `/usr/share/bluebuild/default-flatpaks` directory for maintainers, while for users we would use `(/usr)/etc/bluebuild/default-flatpaks` directory. Reverting to defaults is more reliable as it would avoid users from touching maintainer's modification directly.
I wouldn't modify repo-info.yml doc content, as we restrict it from user's modification & we wouldn't want to potentially ruin yaml parsing just for that.
Only thing that remains is to test this in a VM. And look to potentially make code cleaner.
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario
I have to figure out this part
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario pt.2
* draft(default-flatpaks): Avoid install/remove duplicate loop scenario pt.3
* fix(default-flatpaks): Avoid install/remove duplicate loop scenario
* chore(default-flatpaks): minor grammar adjustment
* draft(default-flatpaks): Account for scenario...
when user sets the same package in install list that is in maintainer's remove list & vice-versa
* fix(default-flatpaks): Account for scenario when user sets the same package in install list that is in maintainer's remove list & vice-versa
* fix(default-flatpaks): Typo in code for combined install list
* chore(default-flatpaks): Remove unnecessary echo
* chore(default-flatpaks): Make directory for user config
* chore(default-flatpaks): Explain user's vs maintainer's flatpak list situation better
* fix(default-flatpaks): Typo in user's configuration for system flatpaks install
* chore(default-flatpaks): There is no need to mkdir parent folder if child folder is created
* chore(default-flatpaks): Make config organization cleaner
Don't use echos for writing configs, use files instead for easier & more intuitive editing.
* fix(default-flatpaks): Copy notification file properly
Made a mistake in variable name
* docs: README fixes
- don't use ambiguous term "live-user"
- capitalize Flatpak
- grammar and phrasing changes
* docs: grammar and phrasing changes in configuration file docs
- replace "maintainer's config" with "image's default config"
- rewrite flatpak list format explanation
* docs: slightly reword local modification section again
* chore(default-flatpaks): Add a missing newline to system flatpak list
---------
Co-authored-by: xynydev
* feat(default-flatpaks): Support for notifications that inform the user before flatpak install/uninstall procedure begins
This can be implemented to be more readable maybe, but this should work.
* chore(default-flatpaks): There is no need to call notifications true statement twice
* chore(default-flatpaks): Make starting notifications consistent with finished ones
* chore(default-flatpaks): Use "listed" term rather than "some"
* chore(default-flatpaks): Use "some" notification only for uninstalling flatpaks
* fix(default-flatpaks): Install/uninstall system flatpaks regardless if current user has permissions or not
Fixes: https://github.com/ublue-os/bling/pull/93
To make notify-send working for --system systemd units, I have to thank @gerblesh for his code & idea in ublue-updater.
I tested this in Silverblue & it works.
However, I would like this to be tested in other DEs like Kinoite too, to see if it's working correctly.
Feel free to improve code if you find some space for that.
@lorduskordus
* Use json parser instead as a more reliable solution on fetching values
* There is no need for echo when parsing json
* Fetch DISPLAY environment variable from printenv
* Make functions for notify-sends, to make script clearer
* Whiteline fixes
* fix:(default-flatpaks): Missing notification for system flatpaks
This approach, while more fragmented, it's cleaner, as there is a clearer separation of root & non-root operations done by flatpak-setup service. This should probably increase security too (but I'm not the expert to talk seriously about that). It also gets rid of some non-harming error for /var data, can't remember it fully.
While it may be confusing for users that they have to type:
`systemctl status --user system-flatpak-setup`
instead of previous:
`systemctl status system-flatpak-setup`
It is something worth sacrificing for the important user-experience fix.
* feat(default-flatpaks): Add info about which flatpaks are installed & uninstalled in notification. Also implement notification enable/disable config support.
* feat(default-flatpaks): Add support for configuring notifications in recipe file
* fix(default-flatpaks): Formatting fixes
* fix(default-flatpaks): Fix "enabling" typo instead of "configuring" notifications
* chore(default-flatpaks): Remove unused yq command
* fix(default-flatpaks): There is no need for 2 double quotes
* fix(default-flatpaks): Always enable systemd services
Ensures that the module always removes Fedora Flatpaks, even if a
system-wide flatpak remote isn't configured for the module.
* chore(default-flatpaks): Add output for result of repo config
* fix(default-flatpaks): Better handle multiple uses of module
* chore(default-flatpaks): Add label to output of existing config
* docs(default-flatpaks): Mention that Flatpak remote can be re-configured
* docs(default-flatpaks): Add second example to README
* docs(default-flatpaks): Clarify repo config in second example
* docs(default-flatpaks): Make example config match other modules
* docs(default-flatpaks): Indent list items in example config
Does seem to work if they aren't indented, but this way matches other
modules and seems to be best practice
There won't be anything to remove unless the module is called more than once, and if it's called more than once, the user would expect every Flatpak to be in the respective lists, so there's no need to call rm -f on it.
