On 18. 06. 22 13:05, Aleksandra Fedorova wrote:
Hi, all,
I'd like to discuss how we can add Build tag in the RPM.
As one of the key points is to turn it into a common standard for rpm packages across the ecosystem, the conversation is currently opened upstream [1] and in RHEL Engineering. And I'd like to get Fedora community on board.
This is not a finalized proposal and I think it is not ready yet to be a Fedora Change. But I want to start a conversation and ask for opinions. There are also some open questions which need help, especially the requirements around build reason. And alternative suggestions are welcome as well.
I've posted long version at https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms/39954
You can comment there (simply login with your FAS id) or here on the mailing list. And I am going to update that post with the new feedback.
Shorter version:
We'd like to introduce Build Number/Tag/Id in the rpm metadata.
By this change we would like to:
- Provide a possibility to change build environment and rebuild rpm
packages without changing their content: neither sources nor spec files.
- Set a common standard for the RPM-based ecosystem, which can be used
not just within Fedora, but also by Remixes, downstreams, SIGs and other distributions.
The most visible impact of the proposal would be the filename change:
Current: dnf-4.9.0-12.fc36.noarch.rpm Proposed: dnf-4.9.0-12.fc36.34897715.noarch.rpm
It can be implemented in two steps:
- Now → Compatibility mode
- Introduce Build tag in the rpm metadata
- Introduce “build reason” to be added to rpm changelog as a top entry
- Enable passing Build tag value to the build in Koji. The value of
the Build tag will be set from Koji build id.
- Introduce macro in Release field of the rpm spec files, which adds
Build tag after the usual disttag Release: 12.%{?dist}%{?build:.%{build}}
- Introduce option to pass “build reason” to a Koji build via koji cli
and fedpkg/centpkg tooling.
- Compatibility mode → Final
- Implement support for the upgrade path on the rpm side in a
compatible way. So that NV(R’=R+B) and NVRB are treated the same.
- Remove %{build} part from Release tag and use independent Build tag
for versioning.
[1] https://github.com/rpm-software-management/rpm/discussions/2031
I have couple concerns/questions.
When modularity was introduced, local builds (outside of MSB) were side tracked not to be part of the MVP. Implementing this later proved out to be rather complicated. So let's focus on the following gotchas from the start here instead please:
1) An user rebuilds a package from Fedora dist-git in local mock, what will be the value of the build tag? How will the local build sort over the official Fedora builds?
2) A packager rebuilds packages from Fedora dist-git in a Copr repo, what will be the value of the build tag? How will the Copr build sort over the official Fedora builds? (This is essentially the same question but the answer might differ.)
3) If every Fedora packager can rebuild anything without a commit, what do we do prevent accidental builds?
As for your open questions, I think that build reason is useful as a changelog message (and should be exposed to users).
I also agree with others in this thread that exposing the build ID so user-visibly isn't great.
packaging@lists.fedoraproject.org