On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote: > On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz > <yselkowi@xxxxxxxxxx> > 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? > > 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. -- Yaakov Selkowitz Principal Software Engineer - Emerging RHEL Red Hat, Inc. -- _______________________________________________ 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
