On Mon, Jun 17, 2024 at 10:38 AM Benjamin Drung <bdr...@ubuntu.com> wrote:
> On Mon, 2024-06-17 at 14:54 +0100, Luca Boccassi wrote: > > On Mon, 17 Jun 2024 at 14:45, Benjamin Drung <bdr...@ubuntu.com> wrote: > > > > > > Hi, > > > > > > Ubuntu started to implement the ELF package metadata spec. It encodes > > > the VERSION_ID from os-release in the osVersion field. Using VERSION_ID > > > was objected to because the version is only set in stone once the > > > release is done. It could change during the development cycle. See > > > https://lists.ubuntu.com/archives/ubuntu-devel/2024-June/043027.html > > > and https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2069599 > > > > > > The proposal is to use VERSION_CODENAME from os-release instead. > > > > > > To me it is not clear enough what is the best approach regarding the > > > spec https://systemd.io/ELF_PACKAGE_METADATA/ here. > > > > > > The key description says "typically"? So could we just use > > > VERSION_CODENAME for osVersion? > > > > > > Or should be use a different key like osVersionCodename to allow third- > > > party users to still use VERSION_ID for osVersion? In that case > > > osVersionCodename should probably added to the well-known keys. > > > > > > What's your take on it? > > > > Hi, > > > > I replied on ubuntu-devel but it's moderated, so the message didn't > > make it through and is waiting for approval. > > > > The gist of it is that this is supposed to be machine readable, and be > > what is commonly understood as the version, which for the next ubuntu > > version would be 23.10. > > > > Given it's sourced from os-release, which is sourced from base-files, > > ideally you'd do an archive-wide rebuild once it is finalized (that > > also gives you builds with newer compiler hardening and other > > niceties). If that's not possible or not wanted, simply omit the > > osVersion field. Parsers need to expect that to be optional, in order > > to avoid breaking on rolling release distros like Arch that do not > > have a version. > > From that perspective Debian and Ubuntu are semi-rolling releases: > Packages are copied over from one release to another. As long as there > is no new upload happening for the package between two release, the > identical binary package will be shipped. So osVersion would still be > unchanged. So osVersion indicated which os version the package was > introduced but not on which release it is running on. Do you suggest to > omit osVersion due to that? > > My initial question targets a different problem: The version number is > finalized (set in stone) on release date. Ubuntu was released on time > except for one case. In such case where we need more time and delay the > release, we won't have time to start an archive wide rebuild of all > package just to correct osVersion in the ELF objects. On the other hand > the version codename is set in stone when the archive for that release > is opened. That's why it was suggested to use the version codename > instead of the version ID. > > IMHO, a rolling release is just that - it is self explanatory. Debian and Ubuntu are definitely not that. In your given scenario, the packages should be rebuilt for the current OS Release with the metadata bumped even if it is the same version o said package. Also, you will definitely be bumping the c libraries with each OS version bump, so you would always want to re-compile them with the current libraries and keep them separate via the OS release based repository directories - yes? I think over-engineering is going on here :) > -- > Benjamin Drung > Debian & Ubuntu Developer >
