<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Jan 2021 at 02:47, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jan 13, 2021 at 6:41 PM Stephen John Smoogen <<a href="mailto:smooge@gmail.com" target="_blank">smooge@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, 13 Jan 2021 at 03:01, redbaronbrowser via CentOS-devel <<a href="mailto:centos-devel@centos.org" target="_blank">centos-devel@centos.org</a>> wrote:<br>
>><br>
>> On Tuesday, January 12, 2021 8:11 PM, Carl George <<a href="mailto:carl@redhat.com" target="_blank">carl@redhat.com</a>> wrote:<br>
>><br>
>> > MBS (the module build system) injects it's own dist tag into the<br>
>> > release. We don't have control over it. The rest of the release<br>
>> > field is right there in the spec file, and is what we get exported<br>
>> > from internal RHEL dist-git to <a href="http://git.centos.org" rel="noreferrer" target="_blank">git.centos.org</a>.<br>
>><br>
>> 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.<br>
>><br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
In my original post I suggested another solution that requires no<br>
policy changes or epoch bumps: Just build again the relevant packages,<br>
e.g. with "30%{dist}.0.2".<br>
<br></blockquote><div><br></div><div>Well building again may not fix this issue depending on how the hex code in %{dist} is made. You could end up needing to build multiple times until you got a bigger version.  [Of course it might also happen the first time it happens but I don't know how they increment per build cluster.]<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's not a long-term solution, though. As redbaronbrowser noted,<br>
long-term, we do need policies around, to make sure we do not have<br>
future similar "downgrade" cases.<br>
<br>
><br>
>><br>
>> > As noted when comparing the spec files, this isn't actually a<br>
>> > downgrade.<br>
>><br>
>> Yes, it is not actually a downgrade.  The output of dnf is misleading.<br>
>><br>
>> Is the next best step to talk about changes to the spec?<br>
>><br>
>> Or is this a dnf bug?<br>
>><br>
>> Or is dnf reporting a "downgrade" when we agree there is no downgrade what we intend to have happen?<br>
>><br>
><br>
> There are several issues and general operating system decisions going on here.<br>
><br>
> 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.<br>
> 2. If you do change repositories you are going to spend the time to make sure you aren't screwing yourself over.<br>
> 3. The tools which are included in the distro are to inform you about the choices you are making.<br>
> 4. In 99% of cases, this would be a downgrade and dnf should warn/stop you from doing this until you tell it otherwise.<br>
> 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.<br>
><br>
> 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.<br>
<br>
Once we have a clear agreement on the expected behavior and the<br>
policies that we want to follow in order to achieve this behavior, I<br>
don't mind opening some bugs.<br>
<br>
IMO:<br>
<br>
1. Migration from any released CentOS Linux to then-current CentOS<br>
Stream should never cause downgrades, whether real or not.<br>
<br>
2. Not sure about the policies to best achieve that. If you think that<br>
a large subset of packages/packagers has a reasonable reason to prefer<br>
"30%{dist}.0.1" over "30.0.1%{dist}", then we have to come up with<br>
some other solution. I hope we can find one that does not require<br>
epoch bumps.<br>
<br></blockquote><div><br></div><div>I think 1 is a good goal but I am not sure how attainable it is. I don't think that policy changes in upstream packages is going to easily happen in the 350 days left of CentOS-8. What may need to happen is someone writes a program which does the conversion so that these fake downgrades are papered over. [Since if you were converting from CentOS-8 to Oracle/Springfield/Cloud Linux/Rocky/etc these 'downgrades' will show up since the module metadata is going to be different for each release]<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Stephen J Smoogen.<br><br></div></div></div>