On 8 August 2018 at 11:43, John Florian <jflorian(a)doubledog.org> wrote:
On 2018-08-08 10:47, Jason Tibbitts wrote:
>>>>>>
>>>>>> "JF" == John Florian <jflorian(a)doubledog.org>
writes:
>
> JF> How difficult would it be to provide modern Python (e.g. 35 or 36)
> JF> in EPEL?
>
> Obviously not that difficult, since it is already there.
By that I assume you mean 34, right? Or am I overlooking something?
>
> The main
> problem is that the way it was done requires that Fedora specfiles grow
> additional complication in order to be built in EPEL, so it isn't just a
> matter of rebuilding a bunch of existing packages.
IIRC, the Software Collection stuff has newer ones that I could use, but all
the install/setup stuff is cumbersome as compared to declaring a few simple
deps in my spec files. If you or anyone has references how to pull SC deps
in neatly, I'd love to see that.
I suppose I'm just in the same boat everyone else is where the life of
Fedora releases are too short to be ideal for production environments and EL
releases are just too old. Of course, if the Fedora releases lived longer,
they also would be(come) too old. It just seems EPEL never quite lives up
to what it ideally could be, the latest offerings from Fedora atop EL.
But that isn't what EPEL was ever meant to be. EPEL was meant to be a
place where long term supported packages (and not some others) that
Fedora Infrastructure and similar projects needed but Red Hat
Enterprise Linux did not have. There have been people who want the
latest offerings but they rarely are the people doing any of the
packaging and maintenance work in EPEL.
And it is a long tail of what the 'latest offerings from Fedora' means
as a good many packages people want to stick to are usually newer than
what RHEL forked off of but older than what is in Fedora. (Various
people want X from Fedora 24 for their system but not what is in
Fedora 28.) This wasn't what EPEL was meant to solve and was never set
up to deal with. It would require a lot of changes to solve this with
a very different compose system than what exists in Fedora currently.
[That would require resources no one ever seems to have.]
--
Stephen J Smoogen.