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. > > 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. -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210113/6f95907d/attachment-0005.html>