Considering that CentOS 8.5 will never be, a year from now (6 month only?) you will not have this issue, as Baron said, with new packages coming to Stream the issue will go away naturally unless you want to move from RHEL to CentOSThanksRoger -------- Original message --------From: Yedidyah Bar David <didi at redhat.com> Date: 2021-01-14 2:47 a.m. (GMT-05:00) To: "The CentOS developers mailing list." <centos-devel at centos.org> Subject: Re: [CentOS-devel] Upgrade to Stream wants to downgrade e.g. httpd On Wed, Jan 13, 2021 at 6:41 PM Stephen John Smoogen <smooge at gmail.com> wrote:>>>> On Wed, 13 Jan 2021 at 03:01, redbaronbrowser via CentOS-devel <centos-devel at centos.org> wrote:>>>> On Tuesday, January 12, 2021 8:11 PM, Carl George <carl at redhat.com> wrote:>>>> > MBS (the module build system) injects it's own dist tag into the>> > release. We don't have control over it. The rest of the release>> > field is right there in the spec file, and is what we get exported>> > from internal RHEL dist-git to git.centos.org.>>>> I understand the part about %{dist} being injected. It is more a question of why is the .0.1 being added after the %{dist} in the spec instead of before it.>>>> I think it is a decision by the package owner to where they wanted this. In Fedora there have been several long packaging conversations over if "30.0.1%{dist}" or "30%{dist}.0.1" is more correct with different groups showing that the corner cases they are interested in are best solved with their decision.>> A change to this would probably need an epoch bump as moving it to later in the versioning would be 'smaller' than the older versions.In my original post I suggested another solution that requires nopolicy changes or epoch bumps: Just build again the relevant packages,e.g. with "30%{dist}.0.2".It's not a long-term solution, though. As redbaronbrowser noted,long-term, we do need policies around, to make sure we do not havefuture similar "downgrade" cases.>>>>> > As noted when comparing the spec files, this isn't actually a>> > downgrade.>>>> Yes, it is not actually a downgrade. The output of dnf is misleading.>>>> Is the next best step to talk about changes to the spec?>>>> Or is this a dnf bug?>>>> Or is dnf reporting a "downgrade" when we agree there is no downgrade what we intend to have happen?>>>> There are several issues and general operating system decisions going on here.>> 1. The general packaging concept that RPM/yum/dnf has followed since year 0 is that normal operations do not change distro repositories but reinstall from scratch.> 2. If you do change repositories you are going to spend the time to make sure you aren't screwing yourself over.> 3. The tools which are included in the distro are to inform you about the choices you are making.> 4. In 99% of cases, this would be a downgrade and dnf should warn/stop you from doing this until you tell it otherwise.> 5. Most of the other packaging rules were done before modules were in effect and thus present corner cases like this where changing the under-neath repository is going to cause modules to go backwards.>> Personally I would report the problem with the place of %dist in this set of packages as a possible bug and work through that to get it fixed. That said, to fix it now may require epoch or other changes to force it not going back in time.Once we have a clear agreement on the expected behavior and thepolicies that we want to follow in order to achieve this behavior, Idon't mind opening some bugs.IMO:1. Migration from any released CentOS Linux to then-current CentOSStream should never cause downgrades, whether real or not.2. Not sure about the policies to best achieve that. If you think thata large subset of packages/packagers has a reasonable reason to prefer"30%{dist}.0.1" over "30.0.1%{dist}", then we have to come up withsome other solution. I hope we can find one that does not requireepoch bumps.Thanks and best regards,-- Didi_______________________________________________CentOS-devel mailing listCentOS-devel at centos.orghttps://lists.centos.org/mailman/listinfo/centos-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210114/df50b14e/attachment.html>