ELF package metadata uses osVersion value that might change

[Robie Basak]

See: https://lists.ubuntu.com/archives/ubuntu-devel/2024-June/043027.html

Blocking proposed migration for now pending discussion in case it helps. I'm not sure if this would stop the new dpkg being used in proposed builds or not though.

[Julian Andres Klode (juliank)]

This is a question for base-files, and as I have said on the mailing list, we have technically committed to these version strings at archive opening and it is used in various artefacts and third party places, since we do set VERSION_ID in os-release - dpkg just inherits it.

[Robie Basak (racb)]

> and it is used in various artefacts and third party places

Please could you expand on this? If we'd just have to adjust base-files and distro-info-data in the case of a schedule change then that's easy and there would be no problem to do it. But locking in artifacts that ship with the release that would require rebuilding is a separate problem. So it would be helpful to have a list of artifacts that are affected, please.

[Benjamin Drung (bdrung)]

Started discussion with upstream: https://lists.freedesktop.org/archives/systemd-devel/2024-June/050438.html

[Benjamin Drung (bdrung)]

From the responses on the systemd-devel list my take is: Do not set osVersion. The osVersion does not reflect the version of the Ubuntu release that package is shipped by, because it can be part of multiple releases without rebuild.

[Launchpad Janitor (janitor)]

This bug was fixed in the package dpkg - 1.22.6ubuntu14

---------------
dpkg (1.22.6ubuntu14) oracular; urgency=medium

  * Export environment variables DEB_BUILD_OS_RELEASE_ID, DEB_HOST_ARCH,
    DEB_SOURCE, and DEB_VERSION when including buildflags.mk (LP: #2070015)
  * buildflags: document RUSTFLAGS
  * buildflags: Always set RUSTFLAGS
  * buildflags: set origin of env vars for ELF package metadata

 -- Benjamin Drung <email address hidden> Fri, 21 Jun 2024 18:46:10 +0200