Yes. CentOS Stream is expected to be backward-compatible with RHEL, for the same reason that each RHEL point release is backward-compatible with previous point releases.
8 thoughts on - Is EPEL Compatible With Stream?
Except in cases where packages in a RHEL point release are being rebased. This is something which is happening with a lot more gusto than in any previous releases so there may be points where say a QT or a gnomelib provides in Stream is ahead of EPEL
So how would one use this shiny bit of information? Is there a way to discover if an EPEL application is going to clobber your system before you install it?
As long as the upstream developers observe semantic versioning, dnf would tell whether or not a package is “broken” by an update (it would have unresolvable dependencies.)
EPEL assumes according to their website RHEL point releases. It will pretty much likely work with CentOS Stream as well, but as Mark said, you’ll see it after you’ve installed the package. On the other hand, EPEL is a community project anyhow, so in real production scenarios you need your own CI for upgrades/ patches.
Kind regards Thomas
Am 03.01.21 um 23:51 schrieb Kay Schenk:
I would expect broken update paths. Also after EOL of CentOS Linux but not sure if they plan a new “playground” repo:
Unless you are doing something like ‘rpm -ivh –force –nodeps’, this problem with EPEL is not going to clobber your system. What will happen is that you can either ‘not upgrade’ to that package in EPEL because nothing provides the needed dependencies in Stream. OR you won’t be able to update to whatever is newer in CentOS Stream because it would break your system because it removes dependencies.
The solution will be that there will be an EPEL-Stream which can have updated packages which will not have this dependency issue. I do not have an ETA on when that will be available
—
—
Stephen J Smoogen.
Those threads probably aren’t relevant to *users* of EPEL, just to package managers. EPEL packages are intended for RHEL installation targets. CentOS Stream won’t necessarily be an appropriate build root for an RHEL installation target, since it may provide ABIs before they’re available in RHEL.
CentOS Stream in this context is interchangeable with RHEL X.(Y+1).
RHEL X.(Y+1) is backward compatible with previous releases, but previous releases aren’t necessarily forward compatible with X.(Y+1). Therefore, using the currently available release of RHEL as a build root for the next release will generally yield usable packages, but using X.(Y+1) may yield packages that aren’t usable on RHEL’s currently available release. But X.(Y+1) should run packages from either build root, so CentOS Stream users shouldn’t typically have any problems with EPEL, regardless.
8 thoughts on - Is EPEL Compatible With Stream?
Except in cases where packages in a RHEL point release are being rebased. This is something which is happening with a lot more gusto than in any previous releases so there may be points where say a QT or a gnomelib provides in Stream is ahead of EPEL
So how would one use this shiny bit of information? Is there a way to discover if an EPEL application is going to clobber your system before you install it?
—
_
°v°
/(_)\
^ ^
Mark LaPierre
****
QT and GTK+ are both stable within a major release, so there’s no reason to worry about those:
https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel-abi-compatibility#Appendix
As long as the upstream developers observe semantic versioning, dnf would tell whether or not a package is “broken” by an update (it would have unresolvable dependencies.)
EPEL assumes according to their website RHEL point releases. It will pretty much likely work with CentOS Stream as well, but as Mark said, you’ll see it after you’ve installed the package. On the other hand, EPEL is a community project anyhow, so in real production scenarios you need your own CI for upgrades/ patches.
Kind regards Thomas
Am 03.01.21 um 23:51 schrieb Kay Schenk:
I would expect broken update paths. Also after EOL of CentOS Linux but not sure if they plan a new “playground” repo:
EPEL-NEXT … see here:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/WCFRJJ3JJFTGD6UMX7WOMCS4F2EVUM5X/
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/LI5MCJEXHLNSZ5UQHFIHGZVPSKCMFWEU/
Unless you are doing something like ‘rpm -ivh –force –nodeps’, this problem with EPEL is not going to clobber your system. What will happen is that you can either ‘not upgrade’ to that package in EPEL because nothing provides the needed dependencies in Stream. OR you won’t be able to update to whatever is newer in CentOS Stream because it would break your system because it removes dependencies.
The solution will be that there will be an EPEL-Stream which can have updated packages which will not have this dependency issue. I do not have an ETA on when that will be available
—
—
Stephen J Smoogen.
Those threads probably aren’t relevant to *users* of EPEL, just to package managers. EPEL packages are intended for RHEL installation targets. CentOS Stream won’t necessarily be an appropriate build root for an RHEL installation target, since it may provide ABIs before they’re available in RHEL.
CentOS Stream in this context is interchangeable with RHEL X.(Y+1).
RHEL X.(Y+1) is backward compatible with previous releases, but previous releases aren’t necessarily forward compatible with X.(Y+1). Therefore, using the currently available release of RHEL as a build root for the next release will generally yield usable packages, but using X.(Y+1) may yield packages that aren’t usable on RHEL’s currently available release. But X.(Y+1) should run packages from either build root, so CentOS Stream users shouldn’t typically have any problems with EPEL, regardless.