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

[Dave Howorth]

On Tue, 18 Jun 2024 11:24:22 +0200
Benjamin Drung <bdrung at ubuntu.com> wrote:
> On Mon, 2024-06-17 at 11:19 -0500, Greg Oliver wrote:
> > On Mon, Jun 17, 2024 at 10:38 AM 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?
> > > 
> > > 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 :)   
> 
> No, Debian and Ubuntu are much bigger than other distributions.
> Currently there are 38,579 source packages in Ubuntu. We will not
> rebuild them every six month for a new release. There will be new
> builds of the package in case it gets updated/changed or a used
> library transitions from one ABI to another.

It seems to me that the ELF package metadata spec is not designed for
your use case. It is designed for a simpler world. It seems you need to
record details of exactly what source version of everything a program
is built against and also details of exactly what binary version of
libraries it is linked against when run. You need both sets of
information to reliably debug problems. I'm not sure of the best way of
achieving that.

> -- 
> Benjamin Drung
> Debian & Ubuntu Developer