<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hello,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mer 23 mar 2022 alle ore 13:56 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">
> Also sadly IMAGE_VERSION doesn't allow + which is used from semver for<br>
> build metadata (such as 1.0.0+21AF26D3 or 1.0.0+20130313144700).<br>
<br>
Ah, interesting. This looks like something to fix in our syntax<br>
descriptio though. I am pretty sure we should allow all characters<br>
that semver requires.<br>
<br>
<span class="gmail_default" style="font-family:monospace,monospace"></span>Can you file an RFE issue about this on github? Or even better, submit<br>
a PR that adds that?<br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">I opened this PR: <a href="https://github.com/systemd/systemd/pull/22841">https://github.com/systemd/systemd/pull/22841</a></div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">This doesn't enable full semver support since that would require allowing A-Z range, but I'm not sure if it is something we really want to enable (uppercase in semver looks quite uncommon by the way).</div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That said, I'd always include some time-based counter in automatic<br>
builds, so that the builds can be ordered. Things like sd-boot's boot<br>
menu entry ordering relies on that.<br>
</blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">This is indeed a good advice.</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> That's pretty useful when storing a relation between the exact update<br>
> bundle that has been used to flash a device, and the system flashed on a<br>
> device. It turns out to be pretty useful when collecting stats about a<br>
> device fleet or when remote managing system versions and their updates.<br>
> So what I would do on os-release would be storing an UUID that is generated<br>
> every time a system image is generated, that UUID can be collected/sent at<br>
> runtime from a device to a remote management service.<br>
<br>
Why wouldn't the IMAGE_VERSION suffice for that? Why pick a UUID where<br>
a version already works?<br></blockquote><div><div style="font-family:monospace,monospace" class="gmail_default"></div><div style="font-family:monospace,monospace" class="gmail_default">I would use the UUID as a further metadata in addition to IMAGE_VERSION, also for the reasons I describe later here in this mail.<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Compared to other options an UUID here would be both reliable and easy to<br>
> handle and generate.<br>
<br>
UUID is are effectively randomly generated. That sucks for build<br>
processes I am sure, simply because they hence aren't reproducible.<br></blockquote><div><br></div><div style="font-family:monospace,monospace" class="gmail_default"><div style="font-family:monospace,monospace" class="gmail_default">Using a reliable digest, such as the one that can be generated with `casync digest`, was my first option, however if you think about an update system such such as RAUC and its bundles, you might still have the same exact filesystem digest mapping to a number of different bundles, since they can bring different hook scripts and whatever.</div><div style="font-family:monospace,monospace" class="gmail_default"><div style="font-family:monospace,monospace" class="gmail_default">I'm
 also aware of scenarios where the same filesystem tree has been used to generate different flash images in order to satisfy different flash sizes / 
NAND technologies.</div></div></div><div style="font-family:monospace,monospace" class="gmail_default"><div style="font-family:monospace,monospace" class="gmail_default">So from a practical point of view having an UUID, and forcing a different one in /etc/os-release every time a filesystem image / RAUC bundle is created allows us to have a reasonable 1:1 mapping between the update artifact and the system image that is on the device.</div><div style="font-family:monospace,monospace" class="gmail_default">Last but not least having it in /etc/os-release makes it pretty convenient to read it (and for sure using an UUID is easier than trying to embed the digest of the filesystem where  /etc/os-release is kept ;) )<br></div><div style="font-family:monospace,monospace" class="gmail_default">Also there is an interesting bonus: UUID is globally unique also in scenarios where users try to delete and recreate version tags without incrementing the version number (or other messy scenarios).<br></div></div><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">
BTW, there's now also this:<br>
<br>
<a href="https://systemd.io/BUILDING_IMAGES/#image-metadata" rel="noreferrer" target="_blank">https://systemd.io/BUILDING_IMAGES/#image-metadata</a><br></blockquote><div><br></div><div><div style="font-family:monospace,monospace" class="gmail_default">Thanks, this feature looks pretty interesting.</div></div><div><br></div><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>