So, maybe I’ve missed something, but is this more complicated than running rpmbuild with different Macros? I’m pretty good with rpms, but I know I don’t always follow Fedora Packaging Guidelines. I know that our DevOps guys will not want to submit builds to Copr, etc., and may not even use a local chroot to assure than BuildRequires is right.
However, if most of the time, they can download a tarball for Python, download the SRPM for rh-python34 or rh-python34, and then run rpmbuild with different options, they would probably be OK, and I could break the back of that work so that they have some wikis and local knowledge to go from.
This is how I complied with security guidelines when I did a lot of rpm building, but generally it was slightly simpler packages than Python. For instance, with Apache httpd, our customers network scanner would say, you are still running httpd X.Y.Z, and so I would pull the SRPM for httpd from Fedora 16 (going back a ways), take a look at the required libraries and versions on Fedora 16, and compare with CentOS 6, then I would copy the tarball and adjust version macros for our own custom version of httpd, make sure to include Conflicts with the system package, and so on.
So, I understand that SCLs aren’t the only way to have other versions, but SCLs prevent conflicts. It gives RedHat customers a step between tarball and rpm that may conflict. That’s what I’m looking for.
However, https://www.softwarecollections.org/en/docs/guide/#Creating_Your_Own_Software_Collections is somewhat imposing, even for me. For our DevOps team, who normally deal with a little bash, a little ansible, and a lot of Jenkins, this is very imposing.
Yes, thanks Dan. Many security scanning tools look for the latest version and flag older versions as being a potential risk. I wanted to be sure that this is what is happening, rather than collections not receiving security updates fast
enough and actually missing an important CVE.
Red Hat Platform Product Management
Phone: 978 392-3173
Cell: 508 740-6549