Hello,
Il giorno mer 23 mar 2022 alle ore 13:56 Lennart Poettering <lennart@xxxxxxxxxxxxxx> ha scritto:
> 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?
I opened this PR: https://github.com/systemd/systemd/pull/22841
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).
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.
This is indeed a good advice.
> 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?
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.
> 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.
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.
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.
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.
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 ;) )
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).
BTW, there's now also this:
https://systemd.io/BUILDING_IMAGES/#image-metadata
Thanks, this feature looks pretty interesting.
Regards,
Davide Bettio.
