[systemd-devel] Please clarify osVersion in ELF package metadata

[Benjamin Drung]

On Mon, 2024-06-17 at 17:57 +0100, Luca Boccassi wrote:
> On Mon, 17 Jun 2024 at 17:45, Benjamin Drung <bdrung at 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 <bdrung at 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?
> 
> Yes. In fact, in the Debian debhelper I do not set osVersion either.

>From the responses here on the list my take is: Do not set osVersion in
Ubuntu since the osVersion does not reflect the version of the Ubuntu
release that package is shipped by.

> > 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.
> 
> Codenames are not great for this purpose, one issue is that not being
> numeric, you cannot do version comparison on them, for example.

Alphabetical sorting works on Ubuntu until we wrap around from z to a
after 13 years (26 releases).

-- 
Benjamin Drung
Debian & Ubuntu Developer