xyny

This template, `startingpoint`, does not change the `$HOME` variable. Based on your link this issue exists/has existed on non-ublue systems too. I am unable to verify the existence of this...

> Ideally, I would imagine that a uBlue repository does not even have a Containerfile This would require commiting to the same approach, or even the same tools as VanillaOS,...

It doesn't duplicate that information, the information is given as build arguments and there are placeholder values for if someone doesn't pass the correct arguments. To go containerfile-less, it should...

Yes, that's an already implemented feature, and can be used to set any set of custom tags on any image. `latest` is added automatically if `tags` isn't set, but after...

> > ```yaml > > base-image: > > url: ghcr.io/ublue-os/silverblue-main > > ``` > > Just realized. I don't think this should be `url:`. Image refs are their own separate...

> I do think that result-image: could be something else like `final-image` or `main-image`. Maybe `final-image` then, definetly not `main-image`, that's an overloaded term. `metadata` would be another possible key...

To spin that argument around: basically everything in the recipe concerns 'the final image', while `metadata` would quite literally be the final images *metadata*, as in it's name, description, labels,...

That is a bit "waffly" IMO yeah 😅

`ref` is still unclear IMO, not sure what it could be instead, though. I think the reason I did it like this is to (1) possibly support matrixing with a...

```yaml base: image: ghcr.io/ublue-os/silverblue-main:40 public-key: https://... # unimplemented, needed for base image verification, would be optional, and automatically supplied for ublue etc. type: ostree # unimplemented, might be needed for...