On Thu, 14 Jan 2021 at 02:47, Yedidyah Bar David <didi at redhat.com> wrote: > 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 no > policy changes or epoch bumps: Just build again the relevant packages, > e.g. with "30%{dist}.0.2". > > 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.] > 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. > > 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] -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210114/b718061c/attachment-0005.html>