[Rpm-maint] [rpm-software-management/rpm] Build-id in RPM (Discussion #2031)

[Aleksandra Fedorova]

Generally speaking what kind of entities we have in play?

1) build itself as an an outcome of a build action in the build system. It should be uniquely identified within the scope of that build system no matter the content, version, reproducibility whatsoever.

2) build environment - the set of configuration options, server settings, dependencies, buildroot repos, mock config,.. everything outside the dist-git sources which has impact on the outcome.

3) build version - some field exposed in a way that it is involved in the calculation of the upgrade path between two rpms.

>From the point of a build system each build needs to have a unique key. The meaning of that key is not important, it is like a primary key field in the database, which simply needs to be unique and allows to store the rest of the data.

For example in Jenkins the unique key for a build is a BUILD_TAG = string of `jenkins-${JOB_NAME}-${BUILD_NUMBER}`.
In case of RHEL the analog would be something like `brew-${brew-buildtarget}-${brew-build id}`

And I agree with Simo that while build time can be used as an implementation of some of a build tag, it is not necessarily the best one, and it very much depends on the way how it the build system operates.

>From the point of reproducible builds it is more interesting to track meaningful build information, thus one needs to encode enough data for the comparison of two builds taken in isolation from their original build systems.

While reproducible build is an interesting topic on its own I think it is not exactly related to the set of problems I listed in the top post.

I would maybe reformulate my original question in a way: **can we provide some generic approach how build system can set the build version at build time, so that it will be used in the calculation of the upgrade path. And what _form_ that build version should have.**

And I would leave it to the build system to decide what this version should be within the restrictions of its _form_, same way how we leave it to maintainer to decide what Release version of a package should be. RPM format itself provides a place for this version, and some constraints, but it doesn't set it.

For example if we agree on the form as number, then some build systems may use build time, some - build id and some will set a custom number which user enters via GUI. It should all be allowed as long as the format and upgrade path rules are set on the rpm side.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2031#discussioncomment-2629524
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2031/comments/2629524 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220425/f1d5c3ec/attachment-0001.html>