Kevin Kofler via devel venit, vidit, dixit 2024-04-28 23:55:37:
> Julian Sikorski wrote:
> > I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> > mame-0.265-1.fc41 is already built against it so I only need to build
> > mame-0.265-1.fc40.1. Can it be done using %autorelease?
>
> No, which is why you should not be using %autorelease.
>
> I would just replace %autorelease with a correctly manually bumped Release
> in the specfile as part of doing the rebuild.
>
> Just letting %autorelease do its thing and ending up with a full bump would
> be incorrect, so it should not even be considered as an option.
Bumping to mame-0.265-1.fc40 to mame-0.265-2.fc40 for a rebuild against
a changed dependency is the normal and recommended way of doing
rebuilds, whether you bump manually or using autolease.
A minor bump (as in <pkgrel>%{?dist}[.<minorbump>]) only comes into play
if a "lower" branch needs to move forward without creating a version
ahead of a "higher" branch. And (independent of autorelease) you cannot
do that unless you use divergent git branches and cherry-picks in
dist-git, in which case "version" makes sense per branch only anyways.
In a dist-git where you work with release branches "contained" in
rawhide - and use macros extensively - you automatically have commits
which you merge down but which don't affect all branches, e.g. rebuild commits
for dependencies or mass rebuilds. I'm not saying this is the best way
of doing things (we should do it differently), but it's a common
pattern. So you can have the "f40 mass rebuild" commit in an f39 branch.
And in a world where you have and accept that, you can also push a
"rebuild for libfoo" to rawhide and merge down to f40 if that is what
you need to have f40 versions <= rawhide versions.
But as others have pointed out, in the light of distrosync and
macro-determined differences etc. we may just as well give up the
illusion that "-5" means the same in different branches, and
consequently lift the sorting policy between different branches.
Michael
--
_______________________________________________
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
