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 CentOS

Thanks
Roger


-------- Original message --------
From: Yedidyah Bar David <didi@redhat.com>
Date: 2021-01-14 2:47 a.m. (GMT-05:00)
To: "The CentOS developers mailing list." <centos-devel@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@gmail.com> wrote:
>
>
>
> On Wed, 13 Jan 2021 at 03:01, redbaronbrowser via CentOS-devel <centos-devel@centos.org> wrote:
>>
>> On Tuesday, January 12, 2021 8:11 PM, Carl George <carl@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 no
policy 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 have
future 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 the
policies that we want to follow in order to achieve this behavior, I
don't mind opening some bugs.

IMO:

1. Migration from any released CentOS Linux to then-current CentOS
Stream should never cause downgrades, whether real or not.

2. Not sure about the policies to best achieve that. If you think that
a 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 with
some other solution. I hope we can find one that does not require
epoch bumps.

Thanks and best regards,
--
Didi

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
https://lists.centos.org/mailman/listinfo/centos-devel