[CentOS-devel] Upgrade to Stream wants to downgrade e.g. httpd

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.html>