Hello,
Il giorno mer 23 mar 2022 alle ore 11:32 Lennart Poettering <lennart@xxxxxxxxxxxxxx> ha scritto:
On Mi, 23.03.22 10:51, Davide Bettio (davide.bettio@xxxxxxxxxxxx) wrote:
Well, if the distribution people build both packages and disk images,
they can set IMAGE_ID/IMAGE_VERSION for the latter. But this should
always be part of building images, not of building packages.
> Can I safely just append those fields at the end of
> the copy of the /etc/os-release file?
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).
> Speaking of BUILD_ID, according to the spec sounds like a field
> reserved to
BUILD_ID? That's a different thing...
https://www.freedesktop.org/software/systemd/man/os-release.html#IMAGE_ID=
vs.
https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID=
> distributions: "BUILD_ID may be used in distributions where the original
> installation image version is important", from my side what I need is to
> identify the git revision + build date of the recipe I'm using to cook the
> image installed on the system, also my plan is to change that ID every time
> 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.
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).
Here my aim was to provide a way to find which build recipe revision has been used or when an image has been built, that is also useful when debugging a device.
> Last but not least, I was looking for a machine parsable unique id, so I
> plan to use BUILD_UUID if it is not kept reserved for other usages, that
> will be an UUID that is freshly generated every time I cook a new image.
What's this for?
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.
Compared to other options an UUID here would be both reliable and easy to handle and generate.
Thanks again for the kind and helpful conversation,
regards,
Davide Bettio.
