Re: /etc/os-release but for images

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 23.03.22 13:38, Davide Bettio (davide.bettio@xxxxxxxxxxxx) wrote:

> > That's the idea: take the packages, build an image, and then append
> > IMAGE_ID/IMAGE_VERSION to it?
>
> Sure, sounds pretty convenient, here my point was about blindly appending
> those additional fields (trusting the distribution didn't already set
> them).

I don't know your distro. But I'd certainly view it as a bug if your
distro fills in these two fields but doesn't actually work based on
pre-built images, but is solely package-based.

> > > I cook a new image, furthermore I plan to replace the whole operating
> > > system image (that I keep read-only) in order to update it, so BUILD_ID
> > > would change at every update (so it sounds slightly different from the
> > > original described semantic).
> >
> > BUILD_ID is not for that. You are looking for IMAGE_VERSION.
>
> IMAGE_VERSION didn't look to me a good option for identifying nightly
> builds, or any kind of build that wasn't cooked from a tagged image build
> recipe.

I think it should be fine for that.

> Also sadly IMAGE_VERSION doesn't allow + which is used from semver for
> build metadata (such as 1.0.0+21AF26D3 or 1.0.0+20130313144700).

Ah, interesting. This looks like something to fix in our syntax
descriptio though. I am pretty sure we should allow all characters
that semver requires.

Can you file an RFE issue about this on github? Or even better, submit
a PR that adds that?

That said, I'd always include some time-based counter in automatic
builds, so that the builds can be ordered. Things like sd-boot's boot
menu entry ordering relies on that.

> That's pretty useful when storing a relation between the exact update
> bundle that has been used to flash a device, and the system flashed on a
> device. It turns out to be pretty useful when collecting stats about a
> device fleet or when remote managing system versions and their updates.
> So what I would do on os-release would be storing an UUID that is generated
> every time a system image is generated, that UUID can be collected/sent at
> runtime from a device to a remote management service.

Why wouldn't the IMAGE_VERSION suffice for that? Why pick a UUID where
a version already works?

> Compared to other options an UUID here would be both reliable and easy to
> handle and generate.

UUID is are effectively randomly generated. That sucks for build
processes I am sure, simply because they hence aren't reproducible.

BTW, there's now also this:

https://systemd.io/BUILDING_IMAGES/#image-metadata

Lennart

--
Lennart Poettering, Berlin