On Sat, Jan 11, 2020 at 12:38 PM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> 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.
>
> Yes, please!!! This is a relatively small step that will make so
> many other things much easier. This is long overdue.
>
> I think this should be done with two principles:
>
> - that this automatization will coexist for a while with manual
> release tags and changelogs that we have now, so they need to be
> compatible. Initially this could be opt-in, and once we get a
> feeling that things works nicely, this could be made opt-out or even
> mandatory.
>
> - only support simple versioning (i.e. don't bother supporting
> pre-release or post-release versions in the dist tag. Packages that
> need that would either need to use tile/caret versioning or not be
> supported for automatic tagging.)
>
I think we have to make sure there's no option in which automatic
tagging is not supportable. Otherwise we can basically never
transition fully over.
> > > 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 understand that <commit-at-version> is basically %version.)
>
To clarify, <commit-at-version> is a counter of the number of commits
since %version was bump, starting at 1. <build-at-version> is a
counter for the number of builds with that
%version-<commit-at-version>, starting at 1.
> In the first variant, builds from the same %version with different
> dist tags would always compare different, so a build from a later
> Fedora release would compare higher.
>
> If builds are tagged automatically, the automatic build-number tag
> cannot be meanigfully compared between different Fedora releases.
> In the second variant, builds from the same %version would compare
> by the build number, which seems useless.
>
> > The first option aligns with our current guidelines suggesting that
> > such bumps go at the end after the DistTag. I personally have felt
> > those were ugly, but there you go. The second option is actually what
> > I use at $DAYJOB for our environment, and I've been pretty pleased
> > with how that works in practice (our buildsystem builds for all target
> > distros from the same commit at once, so the EVRs are rather strictly
> > matched). However, it might not be workable with the whole "Koji and
> > manual build per target" thing.
> Exactly. I don't think this makes sense in Fedora.
>
The only reason I mentioned it is because since we distro-sync between
releases, it doesn't actually matter as much as it used to.
> > The third option is how openSUSE Leap
> > is currently done, primarily to make Leap packages lower than SUSE
> > Linux Enterprise packages (openSUSE Leap can "upgrade" to SLE). I'm
> > not a fan of this scheme as it feels rather "weird" to me.
> Agreed.
>
> > Naturally, there is also an option that would involve enhancing RPM:
> > extending EVR comparisons to factor in the DistTag as a formal
> > property (e.g. EVRD). ALT Linux recently started doing this. I will
> > admit there is some appeal to this, as it makes the distro versioning
> > aspect a property unto itself. This would require making Koji move
> > from NVR to NVRD for its uniqueness constraint, which would be an
> > "interesting" change to implement. This would eliminate the %dist
> > macro entirely, and remove boilerplate entirely from the Release
> > field. This would make all the questions and games about sequencing
> > the values in the Release field to be completely about the unique
> > build versioning of the package. In practice, I think this is just a
> > fancier variant of option two above.
>
> I don't think we should go down this route, unless we know for sure
> that we can't make things work otherwise. I hope we could phase-in
> this automatic tagging in koji, and this will be much easier if we are
> able to do this without changes to rpm and the version comparison
> logic (which is also embedded in countless other places).
>
Another way to go here would be to do EVDR instead of EVRD.
This more closely mirrors the intent that we have in Fedora for newer
distribution releases to always be considered "upgrades" from older
ones.
In this case, it would make sense to enhance RPM and leverage DistTag
for version comparison.
Unlike the equivalent variant with the Release field (like how
openSUSE does), we wouldn't have to take a hit with lots of things
looking like it is "downgrading" for a distro upgrade.
> > > Another question regarding the release field is: how would we deal with
> > > pre-releases and other unsortable versions?
> > > The current doc relies on <extraver> etc. in the release field as per:
> > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_unsortable_versions
> > > Would using the tilde to specify pre-releases in the version field be sufficient
> > > (as described in
> > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde)?
> > > I.e., how can we cater for snapshot releases (e.g. based off a specific git
> > > commit)?
> > >
> >
> > Pre-releases can use tilde versioning, and starting with Fedora 31, we
> > can also use carat versions for post-releases.
> >
> > Carat versioning draft from tibbs from long ago:
> > https://fedoraproject.org/wiki/User:Tibbs/TildeCaretVersioning
>
> I would limit automatic tagging for packages which do "sane"
> versioning, i.e. don't embed any pre-release or post-release data in
> disttag. FPC should finally approve tile+caret versioning guidelines [1,2].
> Right now F30 doesn't support carets, but we could proceed anyway. By
> the time this is ready, F30 should have support and F29 will be EOL.
>
> [1] https://pagure.io/packaging-committee/issue/904
> [2] https://pagure.io/packaging-committee/pull-request/908
>
And carat versions are being backported to EL8:
https://bugzilla.redhat.com/show_bug.cgi?id=1654901
--
真実はいつも一つ！/ 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
