Hi all,
I have a CentOS 8.3 machine I want to upgrade to Stream following [1].
After fighting with it a bit due to oVirt-specific issues [2], I reached the current point: doing 'dnf update' updated everything nicely, but now doing 'dnf distro-sync' wants to downgrade these packages:
Downgrading: httpd x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 1.7 M httpd-filesystem noarch 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 37 k httpd-tools x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 104 k mod_ssl x86_64 1:2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 133 k python3-docutils noarch 0.14-12.module_el8.3.0+389+6a62c88d appstream 1.6 M python36 x86_64 3.6.8-2.module_el8.3.0+389+6a62c88d appstream 19 k
I specifically mention httpd in Subject because that's the one I spent some time looking at, but the issue is general.
I currently have httpd-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64 . It seems to be the result of [3], which says it was built from: git+https://git.centos.org/rpms/httpd#2f74eecf85362e67c403b7b1386a729da3e5c33d .
distro-sync wants to downgrade to 2.4.37-30.module_el8.3.0+462+ba287492.0.1 , which seems to be the result of [4], which says it was built from: git+https://git.centos.org/rpms/httpd#fcb5444a5c0aefcd065e6c4a805a454e4988b78c .
cloning the git repo, and then checking the difference between them, I get:
$ git diff 2f74eecf fcb5444a diff --git a/SPECS/httpd.spec b/SPECS/httpd.spec index 8322bd8..7d66f2e 100644 --- a/SPECS/httpd.spec +++ b/SPECS/httpd.spec @@ -13,7 +13,7 @@ Summary: Apache HTTP Server Name: httpd Version: 2.4.37 -Release: 30%{?dist} +Release: 30%{?dist}.0.1 URL: https://httpd.apache.org/ Source0: https://www.apache.org/dist/httpd/httpd-%%7Bversion%7D.tar.bz2 Source1: centos-noindex-8.0.tar.gz
So:
1. The sources seem to be identical, right now, with the only difference being the 'Release:'.
2. I failed to find where '462+ba287492' and '561+97fdbbcc' are coming from. I assume they are automatically-generated during the build process, but not saved in the dist-git repo. These seem to be what's causing the "newer" version in Stream to be considered a "Downgrade" - 462 < 561. Perhaps they are some kind of timestamps, or increasing counters, etc., and '462' was built earlier than '561', even if in all other regards it should be considered "newer".
3. Perhaps the intention was to have the release in Stream:
Release: 30.0.1%{?dist}
? I think this would have caused this to not be considered a downgrade. I might be missing something.
4. IMO this is a bit confusing/discouraging. Can/Do we do anything so that 8-Stream packages are always >= 8.3 ones? Perhaps a fix should be manually applied to each and every package (if at all), but just generating a report somewhere, perhaps with a place to a link to a bug per package as applicable, can be done in batch, more-or-less, if I got it right. Do we have something like this? Do we want something like this?
5. Perhaps (alternatively?), Stream's version should just be rebuilt, e.g. with 'Release: 30%{?dist}.0.2'.
Thanks and best regards,
[1] https://www.centos.org/centos-stream/
[2] https://github.com/oVirt/ovirt-cockpit-sso/pull/30
[3] https://koji.mbox.centos.org/koji/buildinfo?buildID=14516
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=12971
On 1/10/21 5:18 AM, Yedidyah Bar David wrote:
Hi all,
I have a CentOS 8.3 machine I want to upgrade to Stream following [1].
After fighting with it a bit due to oVirt-specific issues [2], I reached the current point: doing 'dnf update' updated everything nicely, but now doing 'dnf distro-sync' wants to downgrade these packages:
Downgrading: httpd x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 1.7 M httpd-filesystem noarch 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 37 k httpd-tools x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 104 k mod_ssl x86_64 1:2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 133 k python3-docutils noarch 0.14-12.module_el8.3.0+389+6a62c88d appstream 1.6 M python36 x86_64 3.6.8-2.module_el8.3.0+389+6a62c88d appstream 19 k
I specifically mention httpd in Subject because that's the one I spent some time looking at, but the issue is general.
I currently have httpd-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64 . It seems to be the result of [3], which says it was built from: git+https://git.centos.org/rpms/httpd#2f74eecf85362e67c403b7b1386a729da3e5c33d .
distro-sync wants to downgrade to 2.4.37-30.module_el8.3.0+462+ba287492.0.1 , which seems to be the result of [4], which says it was built from: git+https://git.centos.org/rpms/httpd#fcb5444a5c0aefcd065e6c4a805a454e4988b78c .
cloning the git repo, and then checking the difference between them, I get:
$ git diff 2f74eecf fcb5444a diff --git a/SPECS/httpd.spec b/SPECS/httpd.spec index 8322bd8..7d66f2e 100644 --- a/SPECS/httpd.spec +++ b/SPECS/httpd.spec @@ -13,7 +13,7 @@ Summary: Apache HTTP Server Name: httpd Version: 2.4.37 -Release: 30%{?dist} +Release: 30%{?dist}.0.1 URL: https://httpd.apache.org/ Source0: https://www.apache.org/dist/httpd/httpd-%%7Bversion%7D.tar.bz2 Source1: centos-noindex-8.0.tar.gz
So:
- The sources seem to be identical, right now, with the only
difference being the 'Release:'.
- I failed to find where '462+ba287492' and '561+97fdbbcc' are coming
from. I assume they are automatically-generated during the build process, but not saved in the dist-git repo. These seem to be what's causing the "newer" version in Stream to be considered a "Downgrade" - 462 < 561. Perhaps they are some kind of timestamps, or increasing counters, etc., and '462' was built earlier than '561', even if in all other regards it should be considered "newer".
Perhaps the intention was to have the release in Stream:
Release: 30.0.1%{?dist}
? I think this would have caused this to not be considered a downgrade. I might be missing something.
- IMO this is a bit confusing/discouraging. Can/Do we do anything so
that 8-Stream packages are always >= 8.3 ones? Perhaps a fix should be manually applied to each and every package (if at all), but just generating a report somewhere, perhaps with a place to a link to a bug per package as applicable, can be done in batch, more-or-less, if I got it right. Do we have something like this? Do we want something like this?
- Perhaps (alternatively?), Stream's version should just be rebuilt,
e.g. with 'Release: 30%{?dist}.0.2'.
Thanks and best regards,
[1] https://www.centos.org/centos-stream/
[2] https://github.com/oVirt/ovirt-cockpit-sso/pull/30
[3] https://koji.mbox.centos.org/koji/buildinfo?buildID=14516
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=12971
Some things, especially modules, will not matchup between stream and CentOS Linux 8. That is just how it is.
On Tuesday, January 12, 2021 9:16 AM, Johnny Hughes johnny@centos.org wrote:
On 1/10/21 5:18 AM, Yedidyah Bar David wrote:
Hi all, I have a CentOS 8.3 machine I want to upgrade to Stream following [1]. After fighting with it a bit due to oVirt-specific issues [2], I reached the current point: doing 'dnf update' updated everything nicely, but now doing 'dnf distro-sync' wants to downgrade these packages: Downgrading: httpd x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 1.7 M httpd-filesystem noarch 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 37 k httpd-tools x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 104 k mod_ssl x86_64 1:2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 133 k python3-docutils noarch 0.14-12.module_el8.3.0+389+6a62c88d appstream 1.6 M python36 x86_64 3.6.8-2.module_el8.3.0+389+6a62c88d appstream 19 k I specifically mention httpd in Subject because that's the one I spent some time looking at, but the issue is general. I currently have httpd-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64 . It seems to be the result of [3], which says it was built from: git+https://git.centos.org/rpms/httpd#2f74eecf85362e67c403b7b1386a729da3e5c33d . distro-sync wants to downgrade to 2.4.37-30.module_el8.3.0+462+ba287492.0.1 , which seems to be the result of [4], which says it was built from: git+https://git.centos.org/rpms/httpd#fcb5444a5c0aefcd065e6c4a805a454e4988b78c . cloning the git repo, and then checking the difference between them, I get: $ git diff 2f74eecf fcb5444a diff --git a/SPECS/httpd.spec b/SPECS/httpd.spec index 8322bd8..7d66f2e 100644 --- a/SPECS/httpd.spec +++ b/SPECS/httpd.spec @@ -13,7 +13,7 @@ Summary: Apache HTTP Server Name: httpd Version: 2.4.37 -Release: 30%{?dist} +Release: 30%{?dist}.0.1 URL: https://httpd.apache.org/ Source0: https://www.apache.org/dist/httpd/httpd-%%7Bversion%7D.tar.bz2 Source1: centos-noindex-8.0.tar.gz So:
The sources seem to be identical, right now, with the only difference being the 'Release:'.
I failed to find where '462+ba287492' and '561+97fdbbcc' are coming from. I assume they are automatically-generated during the build process, but not saved in the dist-git repo. These seem to be what's causing the "newer" version in Stream to be considered a "Downgrade" - 462 < 561. Perhaps they are some kind of timestamps, or increasing counters, etc., and '462' was built earlier than '561', even if in all other regards it should be considered "newer".
Perhaps the intention was to have the release in Stream: Release: 30.0.1%{?dist}
? I think this would have caused this to not be considered a downgrade. I might be missing something.
IMO this is a bit confusing/discouraging. Can/Do we do anything so that 8-Stream packages are always >= 8.3 ones? Perhaps a fix should be manually applied to each and every package (if at all), but just generating a report somewhere, perhaps with a place to a link to a bug per package as applicable, can be done in batch, more-or-less, if I got it right. Do we have something like this? Do we want something like this?
Perhaps (alternatively?), Stream's version should just be rebuilt, e.g. with 'Release: 30%{?dist}.0.2'.
Thanks and best regards, [1] https://www.centos.org/centos-stream/ [2] https://github.com/oVirt/ovirt-cockpit-sso/pull/30 [3] https://koji.mbox.centos.org/koji/buildinfo?buildID=14516 [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=12971
Some things, especially modules, will not matchup between stream and CentOS Linux 8. That is just how it is.
Please re-read what is asking here because you seem to be skipping over some helpful feedback.
We have no expectation Stream and CentOS/RHEL 8 to perfectly match up. Respectfully, that is not what is being asked.
Instead, please look at this from a novice user's point of view.
A novice is told from the Project Shift FAQ the following: "CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking we expect CentOS Stream to have fewer bugs and more runtime features as it moves forward in time but always giving direct indication of what is going into a RHEL release"
Then the novice's first experience switch to Stream is to get a message from dnf that packages will be "downgraded." This is the point we get to the confusion and discouraging adoption of Stream. The word "downgrade" implies Stream is not living up to being ahead in getting fixes and features.
But unlike a novice, Yedidyah Bar David has done his homework and shown Stream is providing everything it should. All the same sources and patches. It is just the Koji build number causing Stream to get flagged as a "downgrade" instead of being shown as the "side-grade" that is actually being performed.
So just please treat this as a Feature request to avoid novice user confusion:
Why is Stream using "Release: 30%{?dist}.0.1" instead of "Release: 30.0.1%{?dist}"?
The current release format is resulting in misleading output from dnf based on koji build numbers. Since CentOS 8/RHEL 8 will frequently have build number later than Stream, wouldn't it be preferable to prefix the build number such that Stream gets treated by dnf as an upgrade instead of a downgrade?
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. As noted when comparing the spec files, this isn't actually a downgrade. If/when there is an actual change to httpd planned for RHEL 8.4, we'll get a new export, which will be built against the platform:8.4.0 module, which will result in a properly evaluated release field, either by having a higher number at the beginning of the release (e.g. -31), or with module_el8.4.0 in the middle.
On Tue, Jan 12, 2021 at 10:42 AM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Tuesday, January 12, 2021 9:16 AM, Johnny Hughes johnny@centos.org wrote:
On 1/10/21 5:18 AM, Yedidyah Bar David wrote:
Hi all, I have a CentOS 8.3 machine I want to upgrade to Stream following [1]. After fighting with it a bit due to oVirt-specific issues [2], I reached the current point: doing 'dnf update' updated everything nicely, but now doing 'dnf distro-sync' wants to downgrade these packages: Downgrading: httpd x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 1.7 M httpd-filesystem noarch 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 37 k httpd-tools x86_64 2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 104 k mod_ssl x86_64 1:2.4.37-30.module_el8.3.0+462+ba287492.0.1 appstream 133 k python3-docutils noarch 0.14-12.module_el8.3.0+389+6a62c88d appstream 1.6 M python36 x86_64 3.6.8-2.module_el8.3.0+389+6a62c88d appstream 19 k I specifically mention httpd in Subject because that's the one I spent some time looking at, but the issue is general. I currently have httpd-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64 . It seems to be the result of [3], which says it was built from: git+https://git.centos.org/rpms/httpd#2f74eecf85362e67c403b7b1386a729da3e5c33d . distro-sync wants to downgrade to 2.4.37-30.module_el8.3.0+462+ba287492.0.1 , which seems to be the result of [4], which says it was built from: git+https://git.centos.org/rpms/httpd#fcb5444a5c0aefcd065e6c4a805a454e4988b78c . cloning the git repo, and then checking the difference between them, I get: $ git diff 2f74eecf fcb5444a diff --git a/SPECS/httpd.spec b/SPECS/httpd.spec index 8322bd8..7d66f2e 100644 --- a/SPECS/httpd.spec +++ b/SPECS/httpd.spec @@ -13,7 +13,7 @@ Summary: Apache HTTP Server Name: httpd Version: 2.4.37 -Release: 30%{?dist} +Release: 30%{?dist}.0.1 URL: https://httpd.apache.org/ Source0: https://www.apache.org/dist/httpd/httpd-%%7Bversion%7D.tar.bz2 Source1: centos-noindex-8.0.tar.gz So:
The sources seem to be identical, right now, with the only difference being the 'Release:'.
I failed to find where '462+ba287492' and '561+97fdbbcc' are coming from. I assume they are automatically-generated during the build process, but not saved in the dist-git repo. These seem to be what's causing the "newer" version in Stream to be considered a "Downgrade" - 462 < 561. Perhaps they are some kind of timestamps, or increasing counters, etc., and '462' was built earlier than '561', even if in all other regards it should be considered "newer".
Perhaps the intention was to have the release in Stream: Release: 30.0.1%{?dist}
? I think this would have caused this to not be considered a downgrade. I might be missing something.
IMO this is a bit confusing/discouraging. Can/Do we do anything so that 8-Stream packages are always >= 8.3 ones? Perhaps a fix should be manually applied to each and every package (if at all), but just generating a report somewhere, perhaps with a place to a link to a bug per package as applicable, can be done in batch, more-or-less, if I got it right. Do we have something like this? Do we want something like this?
Perhaps (alternatively?), Stream's version should just be rebuilt, e.g. with 'Release: 30%{?dist}.0.2'.
Thanks and best regards, [1] https://www.centos.org/centos-stream/ [2] https://github.com/oVirt/ovirt-cockpit-sso/pull/30 [3] https://koji.mbox.centos.org/koji/buildinfo?buildID=14516 [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=12971
Some things, especially modules, will not matchup between stream and CentOS Linux 8. That is just how it is.
Please re-read what is asking here because you seem to be skipping over some helpful feedback.
We have no expectation Stream and CentOS/RHEL 8 to perfectly match up. Respectfully, that is not what is being asked.
Instead, please look at this from a novice user's point of view.
A novice is told from the Project Shift FAQ the following: "CentOS Stream will be getting fixes and features ahead of RHEL. Generally speaking we expect CentOS Stream to have fewer bugs and more runtime features as it moves forward in time but always giving direct indication of what is going into a RHEL release"
Then the novice's first experience switch to Stream is to get a message from dnf that packages will be "downgraded." This is the point we get to the confusion and discouraging adoption of Stream. The word "downgrade" implies Stream is not living up to being ahead in getting fixes and features.
But unlike a novice, Yedidyah Bar David has done his homework and shown Stream is providing everything it should. All the same sources and patches. It is just the Koji build number causing Stream to get flagged as a "downgrade" instead of being shown as the "side-grade" that is actually being performed.
So just please treat this as a Feature request to avoid novice user confusion:
Why is Stream using "Release: 30%{?dist}.0.1" instead of "Release: 30.0.1%{?dist}"?
The current release format is resulting in misleading output from dnf based on koji build numbers. Since CentOS 8/RHEL 8 will frequently have build number later than Stream, wouldn't it be preferable to prefix the build number such that Stream gets treated by dnf as an upgrade instead of a downgrade?
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
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.
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?
If/when there is an actual change to httpd planned for RHEL 8.4, we'll get a new export, which will be built against the platform:8.4.0 module, which will result in a properly evaluated release field, either by having a higher number at the beginning of the release (e.g. -31), or with module_el8.4.0 in the middle.
True, the problem should self-correct over time as packages get replaced.
But shouldn't the issue come again once Stream 8.4 is released as RHEL 8.4. Won't we have an overlap for a while while RHEL 8.4 is the newer %{dist} while waiting for Stream to organically get 8.5 packages? And then again at the release of RHEL 8.5 while waiting for Stream to get 8.6 packages?
Or will the release of RHEL 8.4 also result in a mass rebuild such that all Stream packages and modules become 8.5 all at once? Will every version bump of RHEL get a Stream mass rebuild?
Lastly, I don't mean to be rude but I would like to restate my primary questions:
What benefits are we trying to achieve with a Release of "30%{dist}.0.1"?
What benefits would be lost in changing it to "30.0.1%{dist}"?
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.
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.
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.
- 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.
- If you do change repositories you are going to spend the time to make sure you aren't screwing yourself over.
- The tools which are included in the distro are to inform you about the choices you are making.
- In 99% of cases, this would be a downgrade and dnf should warn/stop you from doing this until you tell it otherwise.
- 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,
On Thu, 14 Jan 2021 at 02:47, Yedidyah Bar David didi@redhat.com wrote:
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".
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.
- 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.
- If you do change repositories you are going to spend the time to make
sure you aren't screwing yourself over.
- The tools which are included in the distro are to inform you about
the choices you are making.
- In 99% of cases, this would be a downgrade and dnf should warn/stop
you from doing this until you tell it otherwise.
- 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:
- Migration from any released CentOS Linux to then-current CentOS
Stream should never cause downgrades, whether real or not.
- 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]
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 CentOSThanksRoger -------- 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 nopolicy 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 havefuture 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 thepolicies that we want to follow in order to achieve this behavior, Idon't mind opening some bugs.IMO:1. Migration from any released CentOS Linux to then-current CentOSStream should never cause downgrades, whether real or not.2. Not sure about the policies to best achieve that. If you think thata 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 withsome other solution. I hope we can find one that does not requireepoch bumps.Thanks and best regards,-- Didi_______________________________________________CentOS-devel mailing listCentOS-devel@centos.orghttps://lists.centos.org/mailman/listinfo/centos-devel
-
Carl George -
Johnny Hughes -
orkcu -
redbaronbrowser -
Stephen John Smoogen -
Yedidyah Bar David