Closed fiftydinar closed 1 week ago
I'd file this under #146. I'll post a couple notes there and then close this issue. IMO the refactoring wouldn't be that big of a job so it doesn't make sense to fix the current iteration with duct tape.
I think the problem is in default-flatpaks.sh
at lines 112-113 and 120-121.
cp -r
overwrites the destination file, so with every run of the module, it deletes previous configurations.
Using something like this instead should work:
if [ ! -f "/usr/share/bluebuild/default-flatpaks/system/install" ]; then
cp -r "$MODULE_DIRECTORY"/default-flatpaks/config/system/install /usr/share/bluebuild/default-flatpaks/system/install
fi
Edit: It does work on my image. So if you reconsider pushing a duct tape solution before refactoring the whole module, then this might be it.
I believe this change would make the first configuration always take precedence over the later ones, right @lorduskordus ?
This would not improve the situation, as for example overriding the default-flatpaks
configuration of the base image would become impossible.
I'm not sure if I understood, but from my testing:
system/install
list created at build time is correct (when using the module multiple times, new stuff is added to the list)system/install
& system/remove
list in /etc/bluebuild/default-flatpaks
and restarting the system-flatpak-setup.service
manually works too.Ah, maybe I misunderstood this. I'll ping @fiftydinar for good measure.
Ah, maybe I misunderstood this. I'll ping @fiftydinar for good measure.
He's right. Good catch.
I saw his reply earlier but forgot about it.
I made a PR: https://github.com/blue-build/modules/pull/263
Some users faced the issue when trying to include shared flatpaks for all of their images in multi-image setup.
The issue is that the last module definition in the recipe overwrites the 1st one, so only input from the last module definition is taking the place.
That should not happen. Every flatpak ID input from other module definitions should be added to the list, instead of overwriting it.
Here's the example:
Multi image example:
recipe.yml:
shared.yml:
Depending on the recipe order, either of these 2 scenarios happen:
recipe.yml
flatpaks are installing, butshared.yml
flatpaks are notshared.yml
flatpaks are installing, butrecipe.yml
flatpaks are notsingle image recipe.yml example:
This module needs to be refactored, so this issue should be taken in mind when doing that.