Figuring out VanillaOS

[xynydev]

I just took a quick visit to the VanillaOS Discord's #dev channel, and now with VanillaOS Orchid it seems that many are already figuring out how to make custom images for VanillaOS. Vanilla provides tooling very similar to ours (Vib) for this purpose, but it isn't their focus and the UX isn't top speed. Granted their whole OS is built with it, and the tool is technically very capable and can do many more technically capable things, but people making custom images for their own use probably aren't looking to build an OS from scratch...

I think once we get the Ublue stuff moved over to this org, we should get started with building VanillaOS images. Figuring out how rebasing / switching works, making essential modules like package manager & such, and labeling modules based on what base images they are supported on.

[xynydev]

Vanilla has a custom image template repo: https://github.com/Vanilla-OS/custom-image
Kinda reminds me of startingpoint at the start, if ublue was built from the ground up with recipes and not containerfiles. Documentation is still not striking. I'd be tempted to help if I was a Vanilla user and wasn't so caught up with this project. I told Mirko I'd help with some modules to support other base images than Vanilla, but I guess it goes like help yourself first, then others. I'm not really sure even what their stance on modules that they don't need is, as I can't seem to find a lot of related developer communication, maybe a module repository would be the way to go once they support those.

[fiftydinar]

I agree.

We will need to add OS version/name checks in every module, to not let users use them for unsupported OSes.

We can sort modules content into "ublue-os" "vanilla-os" & "shared" folders in bling repo.
"Shared" folder is for modules which support multiple OSes.
This will make it more readable.

Website would automatically fetch that data & sort them.
F.e. if some "ublue-os" module becomes "shared", we move it to "shared" folder + do some other corresponding changes to it & website will automatically show it's content for other supported OSes too. Similar thing is for showing "ublue-os" or "vanilla-os" only modules.

For shared modules, we can specify supported OSes in module.yml in supported-os entry f.e., which will indicate that information.
We can also take this into advantage to make OS check in modules easier, by parsing supported-os entry from module.yml into the module itself.
So using this supported-os entry would be beneficial for all modules too.

[xynydev]

I agree with the supported-os stuff. Not sure the name of that key, but that's what I had planned anyways. Should also add metadata for which modules are supported with the legacy template and which are only supported with the cli-based ones.

We can sort modules content into "ublue-os" "vanilla-os" & "shared" folders in bling repo.

How would this dichotomy work with basing on fedora vs ublue? Wouldn't labeling based on support, and adding links to the distro-specific modules on the "Building on *" pages be enough?

Maybe some type of manual sorting for the modules would be nice...

[fiftydinar]

How would this dichotomy work with basing on fedora vs ublue? Wouldn't labeling based on support, and adding links to the distro-specific modules on the "Building on *" pages be enough?

Maybe some type of manual sorting for the modules would be nice...

It would be nice, but when I think about it, a lot of modules could end in "shared" section, simply because they support base & downstream images/OSes (Fedora / Universal Blue, VanillaOS / something else etc.)

This would make manual work of sorting modules harder.

Maybe we can solve this by sorting it into "fedora-based", "vanillaos-based" folder or something similar.

[xynydev]

I think folder sorting has it's downsides (including minor rewriting of module launch code), and your naming suggestions arent helping that much. Just tagging would be better IMO.

[fiftydinar]

I think that having it in the website is enough, as module maker/maintainer can see there clearly what is he working with.

Manual folder sorting in repo is indeed unnecessary hard task, which we should avoid.

[xynydev]

I think it would also be interesting to look into building a Vib plugin for using BlueBuild modules, as that should be totally possible.

[xynydev]

With our usage of ostree container commit etc., support for VanillaOS would require both CLI and module refactorings. I don't think this is a very urgent matter, as I haven't gotten the beta version of VanillaOS with proper custom image support even running in a VM.

I think we should both explore what Containerfiles generated by Vanilla's Vib tool generally look like, and if there's any special sauce there, and how the CLI should be refactored to detect the different types of base images while allowing user overrides. Only after an MVP is completed, should the OS-depence of modules be thoroughly investigated, improved (to be more agnostic), and documented on the website.

[xynydev]

VanillaOS Orchid is releasing soon.

And I'm Figuring Out VanillaOS live as we speak 🎉 blue-build/cli#206