On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote:
On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz yselkowi@redhat.com wrote:
Since the previous libgweather versions were 40.y and the new versions are 4.4.z, shouldn't there be an Epoch?
I was thinking about this hard as well and I managed to convince myself that it should be fine without an epoch, for two reasons:
- The libgweather package was last part of the F38 package set, and
has been retired ever since (in F39+). Because of that, new F39 installs don't have the package, and people who have updated from F38 to either F39 or current rawhide (F40) don't have the package either (it was obsoleted in fedora-obsolete-packages).
- This only leaves people who would do F38->F40 distro upgrade in
the future, but I think this case should be fine as well because AFAIK both dnf and PackageKit use distro-sync for distro upgrades, so they handle downgrades just fine.
Normally this should have definitely warranted an epoch, but because it was retired for a long time, I believe it should be fine without. We can also always add an epoch in the future if it turns out we missed some case.
What do you think?
Still concerned. You've mentioned those who have already upgraded 38-
rawhide, but what about those who *will* upgrade (e.g. post-branching)
38->40? Since that is a supported upgrade path, and 38 had 40.0, this will be a downgrade. If this wasn't landing until F41 the answer could be different, but it really hasn't been out long enough. After all, the fedora-obsolete-packages entry was set to be removed for F41 for a reason.
Also, what about RHEL upgrades? c9s has libgweather-40.0, this will cause c10s to have 4.4.0.
Welcome to further input on this, but epoch seems the safest bet here.
I expect this only affects places where the package name is hardcoded
CentOS 10 package sync comes to mind. I've added obsoletes and provides for all its subpackages so it should be transparent otherwise.
Please file a PR for content-resolver-input.
Thanks, done:
https://github.com/minimization/content-resolver-input/pull/1055
Thanks, merged.