Hi,
inspired by a different thread here, I did a dnf distro-sync on a CS8 node and noticed that subversion would be downgraded:
from subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7 to subversion-1.10.2-3.module_el8.3.0+393+21cd8ae8
Coming from C8 and swapping the repos to CS8 leads to this situation (especially when doing upgrade instead of distro-sync) but that is not my point.
The above downgrade path recovered that subversion in CS8 still does not have
# rpm -q --changelog subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7.x86_64 | head -3 * Mi Feb 10 2021 Joe Orton jorton@redhat.com - 1.10.2-4 - add security fix for CVE-2020-17525
Such question comes here and there again and again. How does the package update process in CS8 looks like? Is the process mature, any glitches. This subversion update already exists in C8 since February. Why is it not incorporated into CS8?
Would CentOS Stream only be promoted as "upstream" development platform, then ... but its also promoted as successor of CentOS Linux for people with production fleeds.
I do not argue that C8S should be like C8 (in a wider sense) but at least it should have some basal property (like updates are at most after 1 or 2 month all there or so ...).
Any insight about the goal of the current process? Any wiki or doc page for that? Some transparency would be my main goal, to have base for decisions ...
I'd really appreciate any feedback.
Thanks, Leon
On Wed, Aug 4, 2021 at 9:28 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Hi,
inspired by a different thread here, I did a dnf distro-sync on a CS8 node and noticed that subversion would be downgraded:
from subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7 to subversion-1.10.2-3.module_el8.3.0+393+21cd8ae8
First note. Modules Are Not Your Friend(tm). They've caused considerable confusion about dependencies, and the technology was not mature when introduced in RHEL 8. It's not clear that it will ever be mature.
Second note: CS 8.4 has subversion-1.14. I'd encourage the upgrade, the older a version of Subversion the likelier it is to have a long-resolved security or performance issue. I say this as the guy who used to publish the updated Subversion releases for RPMforge. subversion-1.10.2 is over 3 years old now. If you want to run a secure server or deal with awkward, bulky repositories, on your clients, update.
Third note. From the recent adventures with freetype-devel, it's clear that beta packages will show up in CentOS 8 Stream, then be deleted and the SRPMs withdrawn from vault.centos.org, never to show up in RHEL 8. This means that CentOS 8 Stream packages may require rollbacks at arbitrary times, without notice. This is a new problem.
Fourth note: very few companies or developers continue to use Subversion. Most have migrated to git, for a whole stack of reasons, and support for subversion is increasingly difficult to find. You pretty much have to find someone who's been around for a while to maintain it. Maybe not as long as *me*, but it's really fallen out of favor for a number of reasons. Even I use "git-svn" rather than Subversion for my workspaces when compelled to use upstream Subversion repos.
Subversion has some uses, for compelling developers to submit *everything* to the mothership repository before compilation and deployment. And learning it is often faster, especially with the somewhat more popular GUI tools like TortoiseSVN for Windows users. But subversion's developer's unwillingness to provide an "obliterate" function, which was first requested roughly 20 years ago with its first releases, remains a problem for large deployments. Cleaning up after someone *inevitably* commits bulky binaries is frought with adventures: I frankly use "git-svn" to pull it into a git repo, clean up that, and push it back to a new Subversion repo.
Thanks for bringing this to our attention. This is a mistake on the CentOS side. I verified that we should have this module build in both c8 and c8s. I've tagged the c8 module build for the c8s compose and it will be included in the next compose.
I'll be blunt and say that the process for stream 8 is not mature. There are glitches like this. It's all a byproduct of bolting on the Stream workflows after the RHEL8 workflows were already established. For Stream 9 the workflows are the RHEL workflows, and the RHEL maintainers will be directly responsible for their packages. Stream 8 is still technically a rebuild, it's just a rebuild of 8.X+1 content instead of 8.X. The basic process for Stream 8 works something like this.
- RHEL maintainer creates an internal build - Internal build passes gating tests - RHEL maintainer attaches build to errata - Sources exported to c8s branch on git.centos.org - CentOS maintainer rebuilds the sources - CentOS maintainer generates new compose and runs t_functional test suite against it - CentOS maintainer publishes the new compose containing the update
It's absolutely true that the end goal is for CentOS to become the upstream of RHEL. It's also true that it is a work in progress.
On Wed, Aug 4, 2021 at 8:28 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Hi,
inspired by a different thread here, I did a dnf distro-sync on a CS8 node and noticed that subversion would be downgraded:
from subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7 to subversion-1.10.2-3.module_el8.3.0+393+21cd8ae8
Coming from C8 and swapping the repos to CS8 leads to this situation (especially when doing upgrade instead of distro-sync) but that is not my point.
The above downgrade path recovered that subversion in CS8 still does not have
# rpm -q --changelog subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7.x86_64 | head -3
- Mi Feb 10 2021 Joe Orton jorton@redhat.com - 1.10.2-4
- add security fix for CVE-2020-17525
Such question comes here and there again and again. How does the package update process in CS8 looks like? Is the process mature, any glitches. This subversion update already exists in C8 since February. Why is it not incorporated into CS8?
Would CentOS Stream only be promoted as "upstream" development platform, then ... but its also promoted as successor of CentOS Linux for people with production fleeds.
I do not argue that C8S should be like C8 (in a wider sense) but at least it should have some basal property (like updates are at most after 1 or 2 month all there or so ...).
Any insight about the goal of the current process? Any wiki or doc page for that? Some transparency would be my main goal, to have base for decisions ...
I'd really appreciate any feedback.
Thanks, Leon
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 05.08.21 02:07, Carl George wrote:
On Wed, Aug 4, 2021 at 8:28 AM Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
Hi,
inspired by a different thread here, I did a dnf distro-sync on a CS8 node and noticed that subversion would be downgraded:
from subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7 to subversion-1.10.2-3.module_el8.3.0+393+21cd8ae8
Coming from C8 and swapping the repos to CS8 leads to this situation (especially when doing upgrade instead of distro-sync) but that is not my point.
The above downgrade path recovered that subversion in CS8 still does not have
# rpm -q --changelog subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7.x86_64 | head -3
- Mi Feb 10 2021 Joe Orton jorton@redhat.com - 1.10.2-4
- add security fix for CVE-2020-17525
Such question comes here and there again and again. How does the package update process in CS8 looks like? Is the process mature, any glitches. This subversion update already exists in C8 since February. Why is it not incorporated into CS8?
Would CentOS Stream only be promoted as "upstream" development platform, then ... but its also promoted as successor of CentOS Linux for people with production fleeds.
I do not argue that C8S should be like C8 (in a wider sense) but at least it should have some basal property (like updates are at most after 1 or 2 month all there or so ...).
Any insight about the goal of the current process? Any wiki or doc page for that? Some transparency would be my main goal, to have base for decisions ...
I'd really appreciate any feedback.
Thanks, Leon
Thanks for bringing this to our attention. This is a mistake on the CentOS side. I verified that we should have this module build in both c8 and c8s. I've tagged the c8 module build for the c8s compose and it will be included in the next compose.
I'll be blunt and say that the process for stream 8 is not mature. There are glitches like this. It's all a byproduct of bolting on the Stream workflows after the RHEL8 workflows were already established. For Stream 9 the workflows are the RHEL workflows, and the RHEL maintainers will be directly responsible for their packages. Stream 8 is still technically a rebuild, it's just a rebuild of 8.X+1 content instead of 8.X. The basic process for Stream 8 works something like this.
- RHEL maintainer creates an internal build
- Internal build passes gating tests
- RHEL maintainer attaches build to errata
- Sources exported to c8s branch on git.centos.org
- CentOS maintainer rebuilds the sources
- CentOS maintainer generates new compose and runs t_functional test
suite against it
- CentOS maintainer publishes the new compose containing the update
It's absolutely true that the end goal is for CentOS to become the upstream of RHEL. It's also true that it is a work in progress.
Thank you for the honest reply ... I am already looking into CS9 and hopefully the signed packages will be published this month.
-- Leon
-
Carl George -
Leon Fauster -
Nico Kadel-Garcia