On 09/24/2016 07:40 AM, Lamar Owen wrote:
On 09/23/2016 04:42 AM, James Hogarth wrote:
Of course this is where Red Hat intends SCL to fill the gap of the
"supported" new httpd24 and php56 on RHEL ...
https://www.hogarthuk.com/?q=node/15
Unfortunately this is having a knock on effect in the EPEL world
where, since Fedora has no SCL packaging guidelines and RHSCL is not
included in repos EPEL can get built against, we can't package any
applications there that need the newer functionality from RHSCL ...
James, let me start out by saying that I greatly appreciate your work in
and with EPEL. It is fantastic. And even in the context of what I
write below I am a mostly satisfied user of EPEL7; there are just a few
rough edges (and core policies) that are becoming increasingly annoying.
What I am about to suggest is likely to be rather controversial. If the
upstream RHSCL cannot be used, then why can't EPEL be built against
CentOS and then use the CentOS SCL to fix this issue?
That's effectively what I do with https://librelamp.com/ and
https://media.librelamp.com/
I started just building newer PHP versions, then moved to building them
against LibreSSL and building newer versions of some of the other
packages against LibreSSL.
Building against LibreSSL allowed me to have some of the OpenSSL
features not in the CentOS OpenSSL packages without needing to package
them in /opt or /usr/local - which was very useful for building the
bitcoin client but also useful for the ChaCha20/Poly1305 ciphers that
are of benefit to mobile users (provides forward secrecy with less
resources than AES for mobile clients w/o AES hardware assistance)
With PHP it not only gave me access to newer versions of PHP but to the
full set of modules readily available to Fedora users, and things like
WebP support in ImageMagick.
With Apache, it allowed me to offer the latest w/ HTTP/2 support and do
some tweaks like completely disable some of the dangerous ciphers in
mod_ssl so that a default install gets an "A" grade from ssllabs even
before tweaking. Defaults that weren't thought to be dangerous when the
Fedora package that eventually became the RHEL package were created.
The obvious downsides, my packages aren't as well tested before pushed
and I can't guarantee a security response in a timely manner, though I
have been pretty good often beating the RHEL/CentOS packaging of a fix -
but I can't guarantee that.
Just last month I was working on my VLC package for my media repository
and I rebooted to see if I could get bluray to work, probably didn't
need to reboot since nothing kernel was involved but a kernel update had
come in, and the PC wouldn't boot - the error beeps indicated a
corrupted bios (not from anything I did), trying to flash the bios
didn't work, and I was stuck doing any and all package building on a
Thinkpad T410 (I refuse to do package building on a linode VM for
security reasons), just finally built a new workstation last weekend.
But point is, I can't recommend my packages to anyone where delays in
updates or bugs from reduced packaging may result in financial loss.
But I definitely hear where you are coming from, and agree that in many
cases updates to what is in RHEL/EPEL are very beneficial.
It also can be confusing, there's a sound card I want but it requires a
3.17 kernel and I simply don't know if the drivers have been backported
into RHEL/CentOS 3.10 or if they are available in elrepo - without the
sound card physically installed I can't do an lspci to find out if the
driver is available. It's tempting to try to create a kernel repo that
has newer versions of the kernel but with RHEL specific patches and
configurations applied, but I'm afraid there, the benefit wouldn't
really be worth the work (e.g. USB sound cards work just fine, I just
want inexpensive low profile PCI-E with optical out to reduce cable mess)
I think RHEL/CentOS is a great starting point for stability but I guess
I'm saying I am definitely in favor of special use repositories for
cases like the server stack or the multimedia stack where there are
definite benefits to running newer versions.
And IMHO they should be special purpose repositories that require EPEL
and are used only when that purpose is needed, rather than a general
purpose single repository. Let EPEL be the general purpose add-on
repository.
--
-=-
Sent my from my laptop, may not be able to respond timely
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
