Closed fiftydinar closed 4 months ago
xynydev
commented
5 months ago 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).
I'm not sure about that, as yafti is very clearly Universal Blue. I'll follow up with this more later.
fiftydinar
commented
5 months ago 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).
I'm not sure about that, as
yaftiis very clearly Universal Blue. I'll follow up with this more later.
No need for me, it's clear. I thought we could migrate yafti.yml at least, but I decided that it's the best to leave that as it is.
fiftydinar
commented
5 months ago I refactored code now to achieve what I wanted here, but I also added useful docs into files used by default-flatpaks & I made flatpak lists detection & comparison to current flatpaks more reliable now.
Here's the commit description:
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.
fiftydinar
commented
5 months ago I made custom image for this PR based on this latest commit:
rpm-ostree rebase ostree-unverified-registry:ghcr.io/fiftydinar/default-flatpaks-refactor:39
So it is easier for others if they want to test this too.
It's based on Silverblue-main, installs those system flatpaks:
Removes those system flatpaks:
That's it.
fiftydinar
commented
5 months ago I tested these scenarios & it works well:
#
#
#
I find this refactor done, so I will mark this PR as ready:
xynydev
commented
5 months ago Looks great! Haven't got time for an in-depth review right now, but I promise one soon. More general comments on this topic at https://github.com/blue-build/modules/issues/157
fiftydinar
commented
4 months ago Basically the rest of my change reqs in this PR would be documentation phrasing and grammar, which I find would be too laborious to spell out here individually. I'll do a commit for the PR fixing those issues later, if that's alright.
No problem at all, that's even encouraged.
Use
/usr/etc/bluebuild/default-flatpakslocation instead of
/usr/etc/flatpaksIf possible, we should ideally use this location for system modifications:
/usr/share/bluebuild/default-flatpaksWhile having user modifications in:
/usr/etc/bluebuild/default-flatpaksBut 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-setupmodule & 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.