Re: Heads up: libgweather4 to libgweather rename in rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz <yselkowi@xxxxxxxxxx> 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@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.

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@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux