Hello all--
All good in the Stream for me. :)
Because Stream will tend to be more "forward moving" than previous CentOS releases, is it still OK to set up EPEL as a repo? So far, I've only installed terminus fonts from CentOS 8 EPEL, but I'm just wondering about this. Generally, are there any cautions against enabling specific repos to use with Stream?
On Sun, 3 Jan 2021 at 18:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/3/21 2:51 PM, Kay Schenk wrote:
is it still OK to set up EPEL as a repo?
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.
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
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 1/3/21 8:34 PM, Stephen John Smoogen wrote:
On Sun, 3 Jan 2021 at 18:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/3/21 2:51 PM, Kay Schenk wrote:
is it still OK to set up EPEL as a repo?
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.
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?
On 1/3/21 8:05 PM, Mark LaPierre wrote:
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.)
On Mon, Jan 4, 2021 at 6:44 AM Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/3/21 8:05 PM, Mark LaPierre wrote:
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
On Sun, 3 Jan 2021 at 23:05, Mark LaPierre marklapier@gmail.com wrote:
On 1/3/21 8:34 PM, Stephen John Smoogen wrote:
On Sun, 3 Jan 2021 at 18:20, Gordon Messmer gordon.messmer@gmail.com wrote:
On 1/3/21 2:51 PM, Kay Schenk wrote:
is it still OK to set up EPEL as a repo?
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.
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?
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
On 1/3/21 5:34 PM, Stephen John Smoogen wrote:
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
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
Am 03.01.21 um 23:51 schrieb Kay Schenk:
Hello all--
All good in the Stream for me. :)
Because Stream will tend to be more "forward moving" than previous CentOS releases, is it still OK to set up EPEL as a repo? So far, I've only installed terminus fonts from CentOS 8 EPEL, but I'm just wondering about this. Generally, are there any cautions against enabling specific repos to use with Stream?
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...
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
-- Leon
On 1/4/21 3:05 AM, Leon Fauster via CentOS wrote:
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...
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
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.
-
Gordon Messmer -
Kay Schenk -
Leon Fauster -
Mark LaPierre -
Stephen John Smoogen -
Thomas Bendler