On Mon, Apr 08, 2024 at 01:11:22PM +0200, Petr Pisar wrote:
> V Mon, Apr 08, 2024 at 10:49:42AM +0000, Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Mon, Apr 08, 2024 at 12:28:34PM +0200, Petr Pisar wrote:
> > > - It breaks upgrade path in downstream distributions (e.g. fixes in RHEL minor
> > > releases).
> >
> > Hmm, can you provide describe the workflow that is broken in more
> > detail?
> >
> RHEL do updates into older minor distribution versions. E.g. you might want to
> build for RHEL 9.2 and RHEL 9.3. Users staying on 9.2 should update to that
> build for 9.2, users staying on 9.3 to the build for 9.3 and users uprgading
> from 9.2 to 9.3 should update to the build for 9.3 regardeless they updated to
> the 9.2 build before or not.
OK, so you mean that the approach with '.<minorbump>' at the end of Release
doesn't work. Yes, that case is not supported very well.
There is no great solution here, but there are a few options. Which
one makes the most sense depends a lot on the package. But in particular:
- just switch to non-autorelease numbering when introducing the
minorbump, e.g. just do Release: 15%{?dist}.1 and then .2, etc.
Looking at the docs again, the docs are not great, and we should
support this case better. This certainly needs looking into.
> It's bascially the same problem as Fedora has when users upgrade from Fredora
> 40 to 41. Fedora "fixed" the rpmautospec problem by stating that upgrade path
> between Fedoras is not maintained anymore and users need to do "dnf
> distro-sync" to ignore the RPM versioning.
>
> All that stems from tha fact that a number of commits between parallelly
> supported braches is not monotonic.
>
> > > - I sometimes need a different commit message from an RPM changelog entry.
> >
> > That's not a problem, the %changelog entry is customziable, see
> > https://docs.pagure.org/fedora-infra.rpmautospec/autochangelog.html.
> >
> If I understand it correctly
You understand incorrectly ;) Please see the docs linked above.
> the customization is actually dumping a changelog
> into a static file. So instead of a few-line commit one would need to review
> the complete changelog. No, thanks.
>
> > > - I prefer "fedpkg local" over mock (faster, smaller, easier to debug).
> >
> > That also just works.
> >
> With preserving the release numbers. Last time it subsituted the release
> number with a dummy value. Part of the development is comparing old and new
> builds and testing an upgrade path. A dummy release number is not sufficient.
No. I don't know what "last time" means, but it hasn't been like that
since it was officially introduced in Fedora.
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
