Hi, Miro, On Thu, Jun 23, 2022 at 12:15 PM Miro Hrončok <mhron...@redhat.com> wrote: > > 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: > > > > 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 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:
I think these are very valid questions. I didn't think about them at first, but then added at the last moment under the name: "Cross-distribution upgrade paths" in the doc. But I like how you mention Copr and local builds as especially important cases of this, so I will adjust the wording. I don't have a ready to go answer, because I am not sure about the goal. How do we want this to work? Here are just some considerations. > > 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? Afaik currently, if you do a local build, you need to bump an NVR to ensure the upgrade path is set. Then if the base distribution upgrades or rebuilds the package, you would need to bump your version again if you like to preserve the upgrade path. This approach would work exactly the same way after the change, as bumping the Release tag in the sources makes build-related versioning irrelevant. We can agree that by default Build tag in mock environment is unset. Local builds have no build id, and to make clean upgrades bump of Release tag is required. But there are some new possibilities: If you want to create a local rebuild without Release bump, you would be able to pass the build tag value manually and set to whatever you want. For example you can add 1 to existing build tag. Or you could set it to 0. Or to 99999999. The latter is less likely though. If I were to create local builds which are always higher or always lower than builds from the base system, I would probably play with the dist-tag, not build id: $ rpmdev-vercmp 0:1.2.3-12.fc37.15 0:1.2.3-12.localfc37.1 0:1.2.3-12.fc37.15 < 0:1.2.3-12.localfc37.1 There is also a possibility to set default local build tag to be the local timestamp. But I am not sure if it is useful for a local development. > 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.) Similar as above, the questions would be how does it work now, do we want a change or do we want to keep the current setup? CC @Miroslav Suchý > 3) If every Fedora packager can rebuild anything without a commit, what do we > do prevent accidental builds? I think each rebuild should be treated as a new package, thus it would require a new bodhi update, testing, and signing. Which means it will be less likely to accidentally ship it. But as I mentioned in the post, right now we'd like to propose the refactoring, and not a change of the development workflow. Thus I would initially restrict the rebuild possibility to the admin group which handles mass-rebuilds and other admin tasks. Then I would gradually open it up case by case, each case through a separate conversation. Saying that, probably the first case, which I would consider is: is there a problem of an accidental rebuild of a merged code for Fedora Rawhide? What would be the reasons for us to _not_ allow it? > > 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. > I am not convinced about it. Technically we can configure filename to not show build-id at all. But then we will have a confusion, that upgrade path is not visible from a filename. And as it was mentioned elsewhere [1] we already have Epoch tag which works this way, and users hate it for this exact reason. I think that cleaner tags and filenames is a good goal. But I think the requirement "filename should contain all information which is required to calculate the upgrade path between two builds" is valid and probably should be included in the definition of that "cleanliness". [1] https://github.com/rpm-software-management/rpm/discussions/2031#discussioncomment-2767681 > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > -- Aleksandra Fedorova bookwar _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
