@.jstone good call on that aptX thing, I did a search and the things people gotta do to make their headphones work. It's that kind of absurd toil that can just go away
I thought'd be a bit stupid to have both the common upstream image for including common qol and the downest downstream image intended for total customization be both the same repository and codebase.
When the Main docs talk about it's main function it's pretty confusing for someone just wanting to step into this and wanting to layer some packages in a native container
Well, it's a template. It's not intended to be an image by itself but something that is used for you to make your own image based on the uBlue efforts.
Furthest possible upstream would be fedoraproject, and I don't think fedoraproject means total customization of native container images based on uBlue.
Well, it's doing builds and publishing them, but it's not intended for people to directly use as it doesn't really do anything main doesn't (except the template flatpaks install on firstboot)
Well obviously not absolute, maybe Linus Torvalds would be there, and maybe I was going a bit far. I don't think peoples custom images and main are on the same level. If we give instructions like
make a new main, and then switch the FROM field to be main
make a new main, and then switch the FROM field to be main
, I reckon that's a bit confusing. Not to mention that the scope of main is to build all of the desktops whereas one persons custom image should probably only build one desktop by default.
To phrase my confusion differently, what does "starting point" do that main, which was specifically made for that purpose, does not, and why should a weak link be introduced with the potential to diverge and splinter off? What do images inherit from "starting point" that should not be in main?
My intention for startingpoint was as follows: A repository for clear instructions and a fantastic starting point as yall've created for making your own native container image, with clear documentation for all parts so you don't have to get lost in a codebase not made for what you're doing.
To me, "starting point" looks like an attempt to splinter the custom images away from the Ublue project into your own thing, instead of having one organized modular inheritance tree
Starting point is literally in the uBlue org, intended for people making a personal custom image. I don't think we want everybody's custom image where they just changed a few flatpaks and added some rpms to be an official part of the uBlue project.
Main is based on Base, the deprecation was done because it's role and name changed. Main is the upstream image, which other uBlue images are based on. Base was both an image with some goodies and a template for people to use. Main is intended to be those goodies, and startingpoint is intended to be the template.
It's true that it was my plan, and I executed it because I saw it fit. If yall don't want it then alright I'll just remove the repo or something and redo all the documenting on main.
My point is; Why have a repository that serves two purposes, and inherits itself? Why not have a clear structure of inheritance, where the inheritee is another image that serves another purpose?
I've been following discussions in this channel fairly consistently and I'm confused by "starting point" because everyone else was ironing out how to structure the project such that Main functions as a unified template for all of the official AND unofficial images, and the diagram they used, which you created, supported that.
I do think that documentation was/is/should be a priority on the to-do list for Main, but I don't see what would be different from Main in "starting point"
The graph I created specifically included a starting point, and as far as I know nobody was complaining then. As far as I knew, Main was supposed to be just an upstream image, but apparently it actually was not and was intended to be multipurpose.