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.)
> > 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.)
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 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 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
Zbyszek
_______________________________________________
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
