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. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
