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?
EPEL7 is nowhere near as useful as it could be due to versioning policy
and due to the upstream EL7 being so inflexible in versioning. Case in
point is boost, where EL7's 1.53 is just barely too old for lots of
highly useful workstation packages (such as KiCAD, which needs 1.54+).
A software collection is the correct way to do up boost 1.54 for a KiCAD
4.x package for EL7 (CentOS and SL both), but a quick perusal of the
current SCL shows that boost 1.54+ is a requirement for at least two
already supported SCL packages.
In my opinion, the versions of packages that are supported should be
user-needs driven and not so inflexible that, for instance, an easy
upgrade of GNURadio to the latest version from the quite old version
supported in EPEL7 would be done, simply because most enterprise users
of GNURadio are going to need the latest version regardless of the
packaging and versioning guidelines.
Or, in summary, stability should not be equated with version stagnation,
IMHO. As always, I reserve the right to be wrong, etc. And maybe it is
time to get back on the Fedora ratchet on the workstation; not something
I'm looking forward to. At least the Fedora ratchet steps are smaller
than the EL steps, even if they are closer together. Software
Collections helps a great deal, especially in the server space, but
there is just way too much inflexibility in some of the policies to find
that happy medium between 'stable' and 'usable.' And as the update
release versions climb above x.3, it gets harder. Lots harder. And at
x.8 it gets nearly impossible; I'm migrating my work's ownCloud to C7
from the rock-solid C6 box entirely due to PHP versioning issues with an
ownCloud app we want to use, which requires PHP >=5.5 (Software
Collections for C6 gets us to PHP54; SCL for C7 goes farther).
After all, I bought my used Dell Precision M6500 mobile workstation
specifically because it is certified for Red Hat Enterprise Linux use
(most of the Precision mobile workstations can be ordered from Dell with
an RHEL subscription as an equally-well-supported OS option to
Windows). CentOS 7 is perfectly at home on it, and all typical 'laptop'
features that I use just work right out of the box.
If EPEL could build against and require packages in SCL (like the case
of ownCloud; ownCloud's own community packages are available for C6
PHP54_SCL that are now working very well at the 9.1.1 level) that would
make it some easier for users, but it is likely to run way afoul of
EPEL's rather restrictive policies. Barring that, I believe that
ownCloud and Nextcloud could be built in SCL itself relatively easily,
although that is essentially what ownCloud (but not Nextcloud) is
already doing.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
