On Sat, Jun 18, 2022 at 01:05:31PM +0200, 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: > > 1) 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. > > 2) 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 think I understand the problem this is trying to solve, but I have issues with the proposed implementation. Of course, this assumes I understand the problem to solve. My understanding is that we can't look at a built RPM and know where it was built and in what environment it was built. If I have missed something, please let me know. Issues/concerns: 1) Overloading Release again. We did it first with dist tags and now this proposal wants to put build-id in there too. Does the build-id really need to be exposed to users? We have long established the NVR, or NEVRA, naming mechanism and even to this day people are confused by the dist tag since they see that in the built package but not in the spec file. Adding build-id will lead to more confusion and break existing workflows. I am not convinced the build-id needs to be user exposed. 2) Similar to modularity, build-id should have its own tag in the RPM header. If this is going to be done, we should do it right from the beginning. I am aware that modularity dumped a bunch of stuff in Release as well, but I think that was a mistake too. 3) From reading the thread and proposal, a lot of the build-id proposal feels like it's trying to make the depsorting work so you always get the latest version. OK, but that means build-id is being used as another Release value, which I don't think is a good approach. Release is a string, but in practice we've always more or less used it as an int if you strip the dist tag part. Each rebuild of a package that should go to a user should increment this field. Updating the Version should reset Release to 1. Epoch allows for resetting Release as well. We've got a lot of knobs here for depsorting and version sorting to ensure users get the latest build. Let's not add more. If build-id changing or incrementing does mean a user should get a new build, then the Release should increment, which leads me to... 4) As others have stated or suggested, we should go all in on rpmautospec. If we get build-id tied in correctly, we should fully implement rpmautospec so Release is also constructed by the build system entirely at rpmbuild time. We can keep spec files clean and maintain that pull request workflow and cherry-picking across branches without the ever-present collision on Release and changelog. 5) Also go all in on automating (or removing) the spec file changelog. I don't understand what the "build reason" is for above, but isn't every changelog entry in a spec file technically the build reason? I would rather skip the compatibility mode in the proposal and just have it focus directly on the final mode. Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
