Re: Please clarify osVersion in ELF package metadata

[Benjamin Drung <bdrung@xxxxxxxxxx>]

On Tue, 2024-06-18 at 10:13 -0400, Demi Marie Obenour wrote:
> On Tue, Jun 18, 2024 at 11:24:22AM +0200, Benjamin Drung 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.
> 
> How long (in terms of machine time) would be needed to rebuild the
> world?  Fedora does do mass rebuilds for each release.

That depends on the speed of the architecture. Data from our test
rebuilds: Between 1 week for amd64 and 4 weeks for riscv64. The time
needed for rebuilds would be much longer in reality due to dependency
chains, build failures that needs fixing, etc.

How many source package does Fedora have? How long does the rebuild take
in Fedora?

-- 
Benjamin Drung
Debian & Ubuntu Developer