Closed fiftydinar closed 7 months ago
I don't know where you got the idea that we don't currently support this. This is even the topic of the only how-to pages that is currently filled out: https://blue-build.org/how-to/multiple-images/.
Besides, my comment in #144 was just something I thought about, and then eventually thought that what we have now is good, as custom images built out of the same repo are likely to share some components.
The rigidity of this module-based file structure is something that can be discussed, but I don't think that it's urgent since I haven't heard any user complain about this yet. Maybe asking for comments would be good?
I don't know where you got the idea that we don't currently support this. This is even the topic of the only how-to pages that is currently filled out: https://blue-build.org/how-to/multiple-images/.
Besides, my comment in #144 was just something I thought about, and then eventually thought that what we have now is good, as custom images built out of the same repo are likely to share some components.
The rigidity of this module-based file structure is something that can be discussed, but I don't think that it's urgent since I haven't heard any user complain about this yet. Maybe asking for comments would be good?
My bad, I missed this somehow.
I can close this issue if you think it's not relevant, as I made a mistake in assumption
It might be relevant at some point, but it's currently mislabeled. Maybe closing is the best option.
This is something that we do not officially support, but it can be currently achieved in some ways.
@qoijjj's SecureBlue project is the best example of current initialization of multiple custom images: https://github.com/secureblue/secureblue
We have to take in mind that we aim to structurize some of our modules to use
config/module-name/file-input
structure, in order to make file-input independent fromfiles
module & to make it more accessible + documented to the users. F.e. user can put wallpaper file-input inconfig/wallpapers/wallpaper.jpg
instead inusr/share/backgrounds/wallpaper.jpg
Here's the example of structured
systemd
module: https://github.com/ublue-os/bling/pull/144gschema-overrides
module is also taking advantage of this. Unofficialwallpapers
module is going to take advantage of this in the future if merged. https://github.com/ublue-os/bling/pull/135This structurized module hierarchy can potentially make it harder to support configuration of multiple custom images.
What we want is to come up with a way to solve this issue, without loosing structurized module hierarchy support & without breaking current custom image structure compatibility.