Package support on CentOS 8, parity with 7 when?

Issues related to applications and software problems and general support
Post Reply
mathog
Posts: 142
Joined: 2008/07/09 23:52:06

Package support on CentOS 8, parity with 7 when?

Post by mathog » 2020/03/24 23:09:42

The many packages here:

https://www.softwarecollections.org/

are mostly qualified for CentOS 6 and 7 (with tests rated either build:failing or build:passing), However in scanning through several pages there I didn't see even one which was tested, or even available, for CentOS 8. That is a problem since that is where we get Boost and DevToolSet - neither of which has an EL8 version. If need be a full gcc tool set can be built from source, but historically building boost from source has been exceedingly difficult, a task best left to Denis Arnaud, who has provided the last couple of copies of this we have used on CentOS.

This leads me to ask, when should we expect package support for CentOS 8 to reach (approximate) parity with CentOS 7?

User avatar
TrevorH
Forum Moderator
Posts: 28026
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Package support on CentOS 8, parity with 7 when?

Post by TrevorH » 2020/03/24 23:27:53

With the exception of devtoolset (which is already in 8), I think the plan is to retire SCLs as the purpose of the AppStream repo in 8 is to give a (some say) better method of keeping up to date. Packages in AppStream have a much shorter support lifetime than those in BaseOS and new modules will arrive in AppStream. You've already seen that in 8.1 when php:7.3 arrived.
CentOS 6 will die in November 2020 - migrate sooner rather than later!
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 is dead, do not use it.
Full time Geek, part time moderator. Use the FAQ Luke

mathog
Posts: 142
Joined: 2008/07/09 23:52:06

Re: Package support on CentOS 8, parity with 7 when?

Post by mathog » 2020/03/25 00:10:06

TrevorH wrote:
2020/03/24 23:27:53
With the exception of devtoolset (which is already in 8), I think the plan is to retire SCLs as the purpose of the AppStream repo in 8 is to give a (some say) better method of keeping up to date. Packages in AppStream have a much shorter support lifetime than those in BaseOS and new modules will arrive in AppStream. You've already seen that in 8.1 when php:7.3 arrived.
Well, OK, A couple of issues...

1.) The Boost in Appstream is 1.66 and SCL was 1.69.
2.) devtoolset by that name isn't in there, it appears to be gcc-toolset* now.
3.) No "meld".

(1) Was there some reason to back off .03 versions from SCL's CentOS 7 Boost version? Forward I can see, but backwards seems like a risky choice. Are other packages in Appstream older versions than those in SCL? Boost is a problem because we have a lot of binaries linked against 1.69. Probably they can all be rebuilt with 1.66 but I would not bet money on it since Boost has historically been subject to .01 revision changes breaking things. Some program builds made with 1.69 are likely baking in a requirement for a library version >=1.69, and those are going to refuse to run with 1.66 and will have to be recompiled to run on CentOS 8.

(2) is minor - no problem other than the initial confusion.

(3) I use that graphical diff a lot when comparing things. (Among other things, It has the nice feature that one can push blocks of code right or left and then save the changes.) Hmm, wait,wrong repo, that came out of EPEL, not SCL. Still a problem though!

User avatar
jlehtone
Posts: 2589
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Package support on CentOS 8, parity with 7 when?

Post by jlehtone » 2020/03/25 15:23:11

1.
The Boost in CentOS 7 is based on 1.53.0
The Boost in CentOS 8 is based on 1.66.0
Can you tell, when did Red Hat "feature freeze" boost for RHEL 8?
Can you say that RH did cherry-pick from SCL?

The proper question is probably:
It has been possible to contribute to Software Collections. Is it possible to contribute or request a feature to RHEL 8's Appstream?


CentOS 7 is not dead yet. It remains a valid platform to run applications on.


2.
The yum group Development Tools in CentOS 7 contains GCC 4.8.5.
The yum group Development Tools in CentOS 8 contains GCC 8.3.1.

Both were semi-ok at the release.
SCL were introduced to allow co-install of more recent versions to RHEL 6 and 7.
AppStream was designed to offer "re-bases" in RHEL 8.

Is your "we need Developer Toolset" due to 8.3.1 being too old or due to not seeing it?


3.
The "meld" sounds like ediff mode in GNU Emacs.

mathog
Posts: 142
Joined: 2008/07/09 23:52:06

Re: Package support on CentOS 8, parity with 7 when?

Post by mathog » 2020/03/25 18:09:00

jlehtone wrote:
2020/03/25 15:23:11
1.
The Boost in CentOS 7 is based on 1.53.0
The Boost in CentOS 8 is based on 1.66.0
Can you tell, when did Red Hat "feature freeze" boost for RHEL 8?
Can you say that RH did cherry-pick from SCL?
Some release dates from

https://www.boost.org/users/history/

1.72 December 11th, 2019 (current version)
1.69 December 12th, 2018
1.66 December 18th, 2017
1.53 February 4th, 2013

1.53 was unusable in most instances because the target packages required newer versions than that. The 1.69 in SCL worked in every instance where I needed it. Boost is a remarkably unstable package because new libraries are added at virtually every release - if any software package uses a new library it immediately becomes incompatible with all prior versions of Boost. This is software written by other people which we use, I don't have any control over which version of Boost they may require, and since this is academic software some of the developers just assume that the bleeding edge Fedora or Ubuntu they are using is an acceptable development platform for everybody else.

jlehtone wrote:
2020/03/25 15:23:11


The proper question is probably:
It has been possible to contribute to Software Collections. Is it possible to contribute or request a feature to RHEL 8's Appstream?
Agreed. And to that end, my first request would be: "The most recent version of any package added to Apptream should not be older than the most recent one in SCL."
jlehtone wrote:
2020/03/25 15:23:11

2.
The yum group Development Tools in CentOS 7 contains GCC 4.8.5.
The yum group Development Tools in CentOS 8 contains GCC 8.3.1.

Both were semi-ok at the release.
SCL were introduced to allow co-install of more recent versions to RHEL 6 and 7.
AppStream was designed to offer "re-bases" in RHEL 8.

Is your "we need Developer Toolset" due to 8.3.1 being too old or due to not seeing it?
Two reasons I install that and use it. The first is that again, due to the bleeding edge nature of the platforms some of the developers employ their software may not compile with older gcc versions. (Primarily that affects C++ code.) The second is that each new version of gcc generally has better code analysis and so for my own packages (which use C99 these days) I like to eliminate all the warnings so that others never see them. That said, some of the warnings in gcc 9 are verging on a little too finicky. For instance, using strncpy to move a single character will generate a warning that the null was not also added. Which the developer clearly intended since any single character from within a string by definition does not include a null.

The devtoolset packages used the base libraries, with just a few extra pieces which were added if new compilers required them. Are the new gcc-toolset packages the same, or do they bring along their own libraries?
jlehtone wrote:
2020/03/25 15:23:11
3.
The "meld" sounds like ediff mode in GNU Emacs.
Not an Emacs fan. There are several programs like this

https://www.tecmint.com/best-linux-file ... omparison/

Meld isn't necessarily better than some of the others, but it is what I am used to. That said, as far as I can tell neither "meld" nor any of the ones with "diff" in the name are present in CentOS 8 BaseOS or Appstream.

mathog
Posts: 142
Joined: 2008/07/09 23:52:06

Re: Package support on CentOS 8, parity with 7 when?

Post by mathog » 2020/03/25 18:37:28

It wasn't too hard to install meld from source, but only into /usr. When installed into /usr/local (the default) at run time it throws the error:

Code: Select all

Couldn't load Meld-specific CSS (/usr/share/meld/meld.css)
There is a thread on installation problems for other OS's here:

https://gitlab.gnome.org/GNOME/meld/issues/225

To install it on CentOS 8 (as root):

Code: Select all

cd /tmp
wget https://download.gnome.org/sources/meld/3.20/meld-3.20.2.tar.xz
unxz meld-3.20.2.tar.xz
tar -xf meld-3.20.2.tar.
cd meld-3.20.2
dnf install intltool  #if not already installed
python3 setup.py install --prefix=/usr
which meld
#/usr/bin/meld
In cursory testing it seems to be working normally.

mathog
Posts: 142
Joined: 2008/07/09 23:52:06

Re: Package support on CentOS 8, parity with 7 when?

Post by mathog » 2020/03/25 19:09:01

A CentOS 8 system is being brought up to package parity, as much as possible, with the existing CentOS 7 sytems. Packages may come from EPEL or elsewhere. I will modify this post as differences are noted between packages which might cause issues:

1. blas-devel exists on CO7, not CO8. It consists entirely of a symbolic link:

Code: Select all

/usr/lib64/libblas.so -> libblas.so.3.4.2
Installing the blas package on CO8 puts in slightly newer libraries, but does not create the symbolic link without version information. Presumably any program which uses that link will not work on CO8.

mathog
Posts: 142
Joined: 2008/07/09 23:52:06

Re: Package support on CentOS 8, parity with 7 when?

Post by mathog » 2020/03/25 20:44:36

A CentOS 8 system is being brought up to package parity, as much as possible, with the existing CentOS 7 sytems. Packages may come from EPEL or elsewhere. I will modify this post as differences are noted between packages which might cause issues:

1. [RESOLVED] (This is in the "CentOS Power Tools" repository which is not enabled by default.)
blas-devel exists on CO7, not CO8. It consists entirely of a symbolic link:

Code: Select all

/usr/lib64/libblas.so -> libblas.so.3.4.2
Installing the blas package on CO8 puts in slightly newer libraries, but does not create the symbolic link without version information. Presumably any program which uses that link will not work on CO8.


2. [RESOLVED] packages argtable-2.13.7 and argtable-devel-2.13.7 were in EPEL for CO7, no version of either is present in EPEL or Appstream for CO8. Closest matching RPM from rpmfind: 2.13.8 for Fedora Rawhide. Rebuild and install works:

Code: Select all

cd /tmp
wget https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/a/argtable-2.13-18.fc32.src.rpm
rpmbuild --rebuild argtable-2.13-18.fc32.src.rpm
(cd /root/rpmbuild/RPMS/x86_64; rpm -i argtable-devel-2.13-18.el8.x86_64.rpm argtable-2.13-18.el8.x86_64.rpm)
#clean up
3. [RESOLVED] Package btrfs-progs was present in CO7, absent in CO8. Closest matching SRPM from rpmfind: 5.4.2 for Fedora Rawhide. Rebuild and install works (no errors noted, install appears similar to CO7):

Code: Select all

wget https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/b/btrfs-progs-5.4-2.fc32.src.rpm
dnf install zlib-devel
dnf install lzo-devel
dnf install libzstd-devel
dnf install libuuid-devel
dnf install libblkid-devel
dnf install libacl-devel
dnf install e2fsprogs-devel
dnf install asciidoc
dnf install xmlto
rpmbuild --rebuild btrfs-progs-5.4-2.fc32.src.rpm
dnf install /root/rpmbuild/RPMS/x86_64/btrfs-progs-5.4-2.el8.x86_64.rpm
#clean up
4. [RESOLVED] Package bridge-utils-1.5-9 was in CO7, no version is present in BaseOS or Appstream for CO8. Closest matching RPM from rpmfind: 1.6.5 for Fedora 32. Rebuild and install works:

Code: Select all

wget https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/b/bridge-utils-1.6-5.fc32.src.rpm
dnf install libtool
#repo "CentOS Power Tools" which has libsysfs-devel, this version.
#Enable it by modifying: /etc/yum.repos.d/CentOS-PowerTools.repo
dnf install libsysfs-devel
rpmbuild --rebuild bridge-utils-1.6-5.fc32.src.rpm
dnf install /root/rpmbuild/RPMS/x86_64/bridge-utils-1.6-5.el8.x86_64.rpm
#clean up
5. [RESOLVED] A large number of packages related to maven were present in CO7 and are absent in CO8. Examples: nekohtml, becl, apache-commons-logging-adapters, jsch. These all drop a .jar in /usr/share/java. I don't recall which top level package dragged all of these into CO7, and RPM isn't that much help as dependency checking dead ends:

Code: Select all

rpm -q --whatrequires bcel
#nekohtml-1.9.14-13.el7.noarch
rpm -q --whatrequires nekohtml
#no package requires nekohtml
rpm -q --whatrequires jsch
#no package requires jsch
rpm -q --whatrequires commons-cli
#no package requires commons-cli
maven 3.0.5 (CO7) and maven 3.5.4 (CO8) apparently have very different requirements. All of these packages were listed by "rpm -q --requires maven" on CO7 but a different set is listed by the same command on CO8. So it appears that maven itself has changed. This shows that I was using rpm incorrectly with --whatrequires. The syntax which works from here:

https://unix.stackexchange.com/question ... pendencies

is:

Code: Select all

rpm -e --test bcel  2>&1 | grep needed | awk '{print $6}' | sort | uniq
#nekohtml-0:1.9.14-13.el7.noarch
rpm -e --test nekohtml  2>&1 | grep needed | awk '{print $6}' | sort | uniq
#maven-wagon-0:2.4-3.el7.noarch
rpm -e --test maven-wagon  2>&1 | grep needed | awk '{print $6}' | sort | uniq
#aether-connector-wagon-1.13.1-13.el7.noarch
#maven-3.0.5-17.el7.noarch
rpm -e --test maven  2>&1 | grep needed | awk '{print $6}' | sort | uniq
#nothing
rpm -e --test aether-connector-wagon  2>&1 | grep needed | awk '{print $6}' | sort | uniq
#maven-3.0.5-17.el7.noarch
6. [RESOLVED] ffmpeg for CO7 was from nux repo, but there is not currently a CO8 version. Install from rpmfusion instead:

Code: Select all

dnf localinstall --nogpgcheck https://download1.rpmfusion.org/free/el/rpmfusion-free-release-8.noarch.rpm
dnf install --nogpgcheck https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-8.noarch.rp dnf install ffmpeg ffmpeg-devel

7. ganglia, ganglia-gmetad, ganglia-gmond were in EPEL for CO7 but are not for CO8. Build and install like so produced installable RPMs but the gmond apparently is not working properly:

Code: Select all

wget https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/g/ganglia-3.7.2-30.fc32.src.rpm
dnf install perl-Pod-Html-1.22.02-416.el8.noarch
dnf install rsync rrdtool-devel rpcgen libtirpc-devel libmemcached-devel libconfuse-devel 
wget https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/l/libart_lgpl-2.3.21-23.fc32.src.rpm
rpmbuild --rebuild libart_lgpl-2.3.21-23.fc32.src.rpm
dnf install /root/rpmbuild/RPMS/x86_64/libart_lgpl-2.3.21-23.el8.x86_64.rpm /root/rpmbuild/RPMS/x86_64/libart_lgpl-devel-2.3.21-23.el8.x86_64.rpm
dnf install git
rpmbuild --rebuild ganglia-3.7.2-30.fc32.src.rpm
dnf install /root/rpmbuild/RPMS/x86_64/ganglia-3.7.2-30.el8.x86_64.rpm /root/rpmbuild/RPMS/x86_64/ganglia-gmetad-3.7.2-30.el8.x86_64.rpm /root/rpmbuild/RPMS/x86_64/ganglia-gmond-3.7.2-30.el8.x86_64.rpm
#modify /etc/ganglia/gmond.conf to: gexec = yes
#use appropriate network device for this roue
cat >/etc/sysconfig/network-scripts/route-eno1 <<EOD
239.2.11.71 via 0.0.0.0 dev eno1
EOD
systemctl enable gmond.service
systemctl start gmond.service
gstat says that it does not see a gexec. Odd, running gmond with "-d20 -f" that process shows it collecting information for the (one) node (name shown) in this cluster, and it logs the requests on a gstat or telnet to that port. However, gmond does not return any hosts information. Example:

Code: Select all

telnet 192.168.0.121 8649
#returns in part
!ELEMENT HOSTS EMPTY
instead of actual hosts information. So something is wrong with gmond when built this way. There were a few warnings in the build.

Post Reply

Return to “CentOS 8 - General Support”