On 4 April 2016 at 19:13, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 4 April 2016 at 10:47, James Hogarth
> HI all,
> How do others feel and does the Steering Committee feel it might be time
> revisit the SCL question?
There are 2 issues which still have to be dealt with.
1) The upstream Fedora maintainers are not keen on SCL's. We could say
'yay' SCLs but if the packaging guidelines etc don't allow for SCL's
[and they don't seem to
] we aren't getting
them approved into EPEL because the guidelines used to review packages
don't allow or cover them.
I read through all the relevant tickets discussing this over the past 3
years last night and the issue primarily seems to be FPC concerned with
packaging in Fedora but of course EPEL doesn't really play any
consideration in that and the reasons for it are very different. This is
the kind of situation I'd expect the EPEL Steering Committee to at least
have some view so that EPEL doesn't become irrelevant for many things over
the EL7 lifetime. If the issue is indeed FPC then perhaps some EPEL
maintainers, and/or the EPEL Steering Committee, ought to make the EPEL
implications clear there and seek some EPEL only guidelines with no
precedence or implication on Fedora itself.
2) Packages don't just magically appear. You need to have
who will keep up the packages. One of the problems that the SCL group
has been having is that the packages are mostly 'good enough for me'
level where the person packages it up and then doesn't want to do any
further maintenance on it.
I'm a maintainer. I'd love to have my stuff that is either 1) difficult 2)
impossible or 3) lesser quality have the obstacles removed to give the same
quality experience on EPEL that is seen on Fedora.
Reading through the tickets it would appear that maintainers of the
relevant technologies (including RH employees in the RHSCL team) would love
to get things in, but the requirement to go through a full package review,
rather than split out a new branch, when we have such a long tail of
reviews that sit dead would be too onerous. And frankly until the okay is
given, acceptable guidelines in place and the infrastructure to build and
deliver the packages then packages cannot appear - short of magically
defying expectation. We trust our packagers on the main branches, we should
trust our packagers on their SCL branches (assuming that route is taken
which appears sane).
Yes both of these are solvable. We aren't going to solve them
It's been 3+ years of debates ... this is quite a pessimistic and if really
true sad view on things.
On 4 April 2016 at 19:22, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Mon, 4 Apr 2016 17:47:25 +0100
James Hogarth <james.hogarth(a)gmail.com> wrote:
> How do others feel and does the Steering Committee feel it might be
> time to revisit the SCL question?
I'm against using SCL in epel until there are approved Fedora
That's fine in and of itself and a great ideological stance to take but the
reasons and requirements for EPEL differ from Fedora.
MattDM on the tickets discussed how some have expressed to him how they
would like it to stay on ruby196 (for instance) when Fedora main is on
2.2.4 but for the EL case the reverse is true - wanting newer tech on the
The implications for EPEL are somewhat different as well. Whilst Fedora
stays current and thus has no trouble with increasing requirements from
upstream projects EL is a static entity without SCL. Red Hat directs its
users to make use of RHSCL whenever a query is made about a newer compiler,
php, python, ruby, mysql, httpd and so on. Technology is also accelerating
in development - the world today is very different from 10 even 5 years ago.
Can you really blame upstream projects for not wanting to support EOL
technologies such as php53 (and officially upstream php54 now) preferring
users move on to something supported upstream when they hit a bug in it?
EL7 will be around for 8 years yet. I can't see a world even within 2 years
where packaging for EPEL on many things is possible anymore. Given that
they didn't rebase php in EL6 but instead developed RHSCL and directed
people to it when they needed php54+ it doesn't seem likely to see a rebase
in EL7 either.
With Red Hat's requirement on RHSCL for many things now EPEL should surely
have to follow to support its mission statement of:
"Make high quality packages that have been developed, tested, and improved
in Fedora available for RHEL and compatible derivatives such as CentOS and
The FPC folks know what they are doing and can figure out all the
corner cases before we would hit them. Last I heard things were
actually pretty close to passing, but then the people driving it just
gave up or moved on to something else.
I don't blame them for giving up after a 2-3 year debate seemingly going
pretty much nowhere having read through the relevant tickets ...
So, it would take some folks willing to push for guidelines, answer
questions, adjust SCLs, etc and get them approved by FPC.
The thing is the FPC, understandably, looks out for Fedora first and
foremost and due to the general nature of the relationship between Fedora
and RHEL this mostly works (with the list of grandfathered exceptions EL
gets depending on the date it was branched). With the current project
direction of Modularity and the layered container stuff something like SCL
(if not specifically SCL) is pretty much inevitable it seems. But the issue
there is that is not what Red Hat are using today and thus what EPEL would
need to be compatible with.
Whatever route is chosen in this area it should facilitate integration with
RHSCL to be compatible with RHEL (and CentOS would presumably adapt their
SCL SIG accordingly if a common set of provides couldn't be agreed on). If
it's not then EPEL gets sidelined.
So yes it it'll take time but can EPEL really exist as it is - base only -
for the duration of EL7 and still achieve it's goal, and what impact would
missing this have on our users and the reputation of EPEL as the best
extension to a RHEL based system?