No description
1e1197dd0b
* 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 |
||
|---|---|---|
| .github | ||
| empty | ||
| modules | ||
| Containerfile | ||
| cosign.pub | ||
| LICENSE | ||
| modules.json | ||
| README.md | ||
bling
This repository containes modules to use in recipe.yml. See list of modules in ./modules
Usage
You can add this to your Containerfile to copy the modules from this image over:
COPY --from=ghcr.io/ublue-os/bling:latest /modules /tmp/modules/
Verification
These images are signed with sisgstore's cosign. You can verify the signature by downloading the cosign.pub key from this repo and running the following command:
cosign verify --key cosign.pub ghcr.io/ublue-os/bling
See what is in this image
Raw commands
NOTE: This makes it so you need to extract everything from the base image!
podman save ghcr.io/ublue-os/bling:latest -o bling.tar
tar xf bling.tar && rm bling.tar
tar xf *.tar
This should extract the image in a way that you can see everything in it!
Using Dive
This method allows you to inspect the image through a TUI
dive ghcr.io/ublue-os/bling:latest