Re: Please clarify osVersion in ELF package metadata

[Luca Boccassi <luca.boccassi@xxxxxxxxx>]

On Tue, 18 Jun 2024 at 13:30, Dave Howorth <systemd@xxxxxxxxxxxxxx> wrote:
>
> On Tue, 18 Jun 2024 11:24:22 +0200
> Benjamin Drung <bdrung@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > wrote:
> > > > On Mon, 2024-06-17 at 14:54 +0100, Luca Boccassi wrote:
> > > > > On Mon, 17 Jun 2024 at 14:45, Benjamin Drung
> > > > > <bdrung@xxxxxxxxxx> 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.

This is absolutely untrue, I have no idea where you got that
impression, but it is most definitely wrong. It is 100% designed for
that use case too.