Description of problem:
1.5 in rawhide/f30 1.7 in f29 - System upgrade to 30 downgrade.
Version-Release number of selected component (if applicable):
Downgrades package when upgrading from f29 to f30.
Should upgrade to latest version.
Note that since 2019-02-19, there's also a branched f30 branch, meaning
that both f30 and master shall receive the update.
IIRC, monotonicly increasing version throughout the Fedora releases was
explicit guarded in the past, not sure why this update:
(f28 is still in testing, not pushed:
was allowed to become stable in the first place, since it would make
such equations not longer hold (misbehaviour of dist.rpmdeplint
* * *
Anyway, the typical workflow is:
1. start with master branch, which shall always be the tip
(per the assumptions that used to get guarded explicitly
in the past)
2. backpropagate the changes in master bracnh back to release
branches, starting with the latest greatest (f30 now),
preferably using "git merge --ff-only", stopping when you
think you are back in history enough (generally, ABI must
not break in the release branches, so if that's the case,
change it in Rawhide only and announce the break on
Following the step 2., you cannot get into this undesired state
that master (Rawhide) or generally newer release branches (f30 here)
carry older version of the package than some older distro releases
(f29 and possibly f28 here).
This has been fixed with upload / move to 1.8.
Package quality is not good.