On Tue, Jan 28, 2020 at 6:12 PM Stasiek Michalski <hellcp@xxxxxxxxxxxx> wrote:
>
>
> On Tue, Jan 28, 2020 at 23:57, Dan Čermák
> <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote:
> > Neal Gompa <ngompa13@xxxxxxxxx> writes:
> >
> >> On Tue, Jan 28, 2020 at 7:27 AM Pierre-Yves Chibon
> >> <pingou@xxxxxxxxxxxx> wrote:
> >>>
> >>> On Fri, Jan 10, 2020 at 09:54:59PM -0500, Neal Gompa wrote:
> >>> > On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon
> >>> <pingou@xxxxxxxxxxxx> wrote:
> >>> > >
> >>> > >
> >>> > > The release field would need to be set by koji ignoring
> >>> whatever is in the spec
> >>> > > file. How do we want to do this?
> >>> > > - Based on dates?
> >>> > > - Using an always increasing integer?
> >>> > > - Using the number of successful builds since the last time
> >>> the version field changed?
> >>> > > - Another idea?
> >>> > >
> >>> > > The third option looks like to be the one closest to our
> >>> current behavior.
> >>> > >
> >>> >
> >>> > I always envisioned that we'd use a variant of the third option.
> >>> >
> >>> > The options I've thought of:
> >>> >
> >>> > * <commit-at-version>%{dist}.<build-at-version>
> >>> > * <commit-at-version>.<build-at-version>%{?dist}
> >>> > * %{dist}.<commit-at-version>.<build-at-version>
> >>>
> >>> I've been thinking a bit about this and been wondering any reason
> >>> why not to do
> >>> simply?
> >>> <build-at-version>%{dist}
> >>>
> >>> This would basically mimic what we are currently doing by hand, it
> >>> would be the
> >>> less changes to our current way of working (making opting-in
> >>> smoother).
> >>>
> >>
> >> If we're not doing automatic builds, sure. I've been going on two
> >> big
> >> assumptions:
> >>
> >> 1. We're going to do automatic building
> >> 2. We need *some* kind of stable leading portion of release for
> >> packagers to use for specified dependencies, especially
> >> Obsoletes+Provides combos.
> >
> > How is openSUSE taking care of 2 then? OBS bumps the release on each
> > rebuild and that can result in crazily high release numbers. I assume
> > they got a mechanism for Obsoletes+Provides and we could use that too?
>
> You got me curious there, so I looked it up with dnf, the highest
> release
> number in Factory is 1475.12 and it belongs to elib, which had its
> source/
> patches last updated 13 years ago, and its spec/changes 5 years ago.
>
The original commit of that package[1] had an absurdly high Release
number, so OBS stuck to it. At the fourth commit[2], the version was
synced and updated to 1451. The original autobuild system had a
Release value sync mechanism which I assume was dropped as part of the
migration from autobuild to OBS. That system likely synced the state
of that value as it was rebuilt without source changes. After that
point, we finally arrive at when the in-spec value was set to zero by
Stephen Kulow[3]. But regardless, OBS kept that value and kept
incrementing it on further commits, leading to the 1475 we have now.
There hasn't been a new version of elib to trigger OBS to reset the
Release value back to zero, so that's why the value is ridiculously
high. There have been 12 builds of the latest commit of elib (hence
the 12).
So if elib were theoretically replaced with something else, you'd do
the following:
Obsoletes: elib < 1.0-1476
Provides: elib = 1.0-1476
[1]: https://build.opensuse.org/package/view_file/openSUSE:Factory/elib/elib.spec?expand=1&rev=98133cb490cebaf272c34d2316c6fb81
[2]: https://build.opensuse.org/package/rdiff/openSUSE:Factory/elib?linkrev=base&rev=4
[3]: https://build.opensuse.org/package/rdiff/openSUSE:Factory/elib?linkrev=base&rev=13
--
真実はいつも一つ！/ 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
