<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hello,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 23 mar 2022 alle ore 11:32 Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mi, 23.03.22 10:51, Davide Bettio (<a href="mailto:davide.bettio@secomind.com" target="_blank">davide.bettio@secomind.com</a>) wrote:<br>
<span class="gmail_default" style="font-family:monospace,monospace"></span><br>
Well, if the distribution people build both packages and disk images,<br>
they can set IMAGE_ID/IMAGE_VERSION for the latter. But this should<br>
always be part of building images, not of building packages.<br>
<br>
> Can I safely just append those fields at the end of<br>
> the copy of the /etc/os-release file?<br>
<br>
That's the idea: take the packages, build an image, and then append<br>
IMAGE_ID/IMAGE_VERSION to it?<br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">Sure, sounds pretty convenient, here my point was about blindly appending those additional fields (trusting the distribution didn't already set them). </div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Speaking of BUILD_ID, according to the spec sounds like a field<br>
> reserved to<br>
<br>
BUILD_ID? That's a different thing...<br>
<br>
<a href="https://www.freedesktop.org/software/systemd/man/os-release.html#IMAGE_ID=" rel="noreferrer" target="_blank">https://www.freedesktop.org/software/systemd/man/os-release.html#IMAGE_ID=</a><br>
vs.<br>
<a href="https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID=" rel="noreferrer" target="_blank">https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID=</a><br>
<br>
> distributions: "BUILD_ID may be used in distributions where the original<br>
> installation image version is important", from my side what I need is to<br>
> identify the git revision + build date of the recipe I'm using to cook the<br>
> image installed on the system, also my plan is to change that ID every time<br>
> I cook a new image, furthermore I plan to replace the whole operating<br>
> system image (that I keep read-only) in order to update it, so BUILD_ID<br>
> would change at every update (so it sounds slightly different from the<br>
> original described semantic).<br>
<br>
BUILD_ID is not for that. You are looking for IMAGE_VERSION.<br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">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.</div><div style="font-family:monospace,monospace" class="gmail_default">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).</div><div style="font-family:monospace,monospace" class="gmail_default">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.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Last but not least, I was looking for a machine parsable unique id, so I<br>
> plan to use BUILD_UUID if it is not kept reserved for other usages, that<br>
> will be an UUID that is freshly generated every time I cook a new image.<br>
<br>
What's this for?<br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">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.<br></div></div><div><div style="font-family:monospace,monospace" class="gmail_default">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.</div><div style="font-family:monospace,monospace" class="gmail_default">Compared to other options an UUID here would be both reliable and easy to handle and generate.<br></div></div><div><div style="font-family:monospace,monospace" class="gmail_default"></div><div style="font-family:monospace,monospace" class="gmail_default">Thanks again for the kind and helpful conversation,</div><div style="font-family:monospace,monospace" class="gmail_default">regards,</div><div style="font-family:monospace,monospace" class="gmail_default">Davide Bettio.</div><div style="font-family:monospace,monospace" class="gmail_default"></div><br></div></div></div>