On Thu, Jun 23, 2022 at 8:25 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > Hi, Miro, > > On Thu, Jun 23, 2022 at 12:15 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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. > I think it makes sense to just set it to zero by default. > > 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ý > I think we'll want to introduce sticky vendors to the Fedora ecosystem to deal with this. Otherwise we'll have EVRB games between sources. Users generally want packages coming from a particular source and following that track makes sense. DNF has the capability to do this if you set "allow_vendor_change=False" in dnf.conf. See: https://dnf.readthedocs.io/en/latest/conf_ref.html#allow-vendor-change-label > > 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? > The most compelling reason would be storage. Koji keeps the binaries of every successful build. We need some policy changes to keep this from turning into even more of a problem than it is now. > > > > 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 > It's important for a non-obvious reason: it's pretty much the only way to ensure when repodata is made, that multiple builds can live safely in the same repository. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
