Hi all,
Just a quick heads up that I'm in the process of renaming libgweather4 package back to libgweather - we only ship a single libgweather version in rawhide (and in F39), so there is no need any more to have the API version encoded in the package name in order to make it parallel installable.
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.
On Wed, 2024-01-10 at 17:59 +0100, Kalev Lember wrote:
Just a quick heads up that I'm in the process of renaming libgweather4 package back to libgweather - we only ship a single libgweather version in rawhide (and in F39), so there is no need any more to have the API version encoded in the package name in order to make it parallel installable.
Since the previous libgweather versions were 40.y and the new versions are 4.4.z, shouldn't there be an Epoch?
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.
Hi Yaakov,
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:
1) 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).
2) 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?
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
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.
On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz yselkowi@redhat.com wrote:
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.
I agree with Yaakov here.
While you're correct that the standard upgrade mechanism now defaults to using `dnf distro-sync`, it's not the ONLY upgrade path that people take. There are a huge number of users who still insist on doing a basic DNF upgrade, no matter how much documentation we write. This WILL cause issues for them and will translate into bug reports that need to be at least triaged. So please, just support a clean upgrade path with the epoch bump.
Also, what about RHEL upgrades? c9s has libgweather-40.0, this will cause c10s to have 4.4.0.
RHEL major upgrades have special tooling, so I wouldn't worry about that.
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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thanks for helping think about this, both of you! Let me try to reply to both of your emails in the same reply.
On Wed, Jan 10, 2024 at 8:04 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz yselkowi@redhat.com wrote:
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.
Replying to Yaakov here: I actually mentioned this as case (2) above, where my idea was that because dnf and PackageKit distro upgrades both use the "distro-sync" method by default, they can handle package downgrades just fine when updating from F38->F40.
However, Stephan then found a hole in the idea:
I agree with Yaakov here.
While you're correct that the standard upgrade mechanism now defaults to using `dnf distro-sync`, it's not the ONLY upgrade path that people take. There are a huge number of users who still insist on doing a basic DNF upgrade, no matter how much documentation we write. This WILL cause issues for them and will translate into bug reports that need to be at least triaged. So please, just support a clean upgrade path with the epoch bump.
Ah, and that's a fair point. I agree that there are probably a ton of people just doing dnf update across distro versions.
However, I'm still a bit reluctant to add an epoch to libgweather, and not because of the one extra Epoch line in libgweather's spec file, but because of all other packages that would then need to remember to use the epoch when they want to express a versioned dependency on libgweather. E.g. 'Requires: libgweather >= 4.5' would match _any_ libgweather version if the epoch is set to 1, and packages would need to use 'Requires: libgweather >= 1:4.5' instead.
So, thinking of alternatives to epoch (and yes, I realize that my timing was bad here and I should have just waited for F40 branching before doing the rename), I suddenly realized that nothing in F38 actually uses the old libgweather at all - we got everything ported over to libgweather4, but failed to retire libgweather in time.
And that opens up a new possibility: we could add libgweather to fedora-obsoletes-packages in F38, and by the time F40 is released in several months time, everybody's F40 systems will have gotten rid of the old libgweather package and we get a nice clean upgrade path from F38->F40, without having to worry about adding epoch.
How does that sound? Also keep in mind that the above is only to cater for people who try to use an unsupported upgrade method - dnf and PackageKit/gnome-software distro upgrades should already work fine without it.
Also, what about RHEL upgrades? c9s has libgweather-40.0, this will
cause c10s to have 4.4.0.
RHEL major upgrades have special tooling, so I wouldn't worry about that.
That's good to hear - that makes everything a whole lot easier. If RHEL major upgrades relied on regular Obsoletes and Provides, we'd have to be much more conservative on Fedora side (in all packages, not talking about libgweather here) and keep the upgrade path not just for 2 Fedora releases, but a whole lot longer, so that they'd cover the time between major RHEL versions.
-
Kalev Lember -
Stephen Gallagher -
Yaakov Selkowitz