Re: [RFC] Build tag in RPM: from NVR to NVRB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux