SCIENTIFIC-LINUX-USERS Archives

November 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sat, 11 Nov 2017 09:28:58 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
On Fri, Nov 10, 2017 at 5:26 PM, ToddAndMargo <[log in to unmask]> wrote:
> Dear List,
>
> I learned something I did not realize about EPEL
> (Extra Packages for Enterprise Linux):
>
>
> https://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterprise_Linux_.28or_EPEL.29.3F
>
>     "EPEL packages are usually based on their Fedora counterparts
>      and will never conflict with or replace packages in the base
>      Enterprise Linux distributions."
>
> So basically, if you need something fixed or updated that is
> already in RHEL, EPEL will not update beyond RHEL.

Our friends over at RHEL do provide newer versions of components. They
put them in the software collections libraries, so that they're
parellel to but carefully do not replace the standard versions.This
includings leading, and bleeding versions, of Python, MySQL, MariaDB,
The "yum-software-collections" package gives pretty good yum based
access to those. They work, and I've personally published several
hundred RPM's using that structure to publish packages that would
overlapped with system libraries.

RPMforge, aka repoforge, used to publish newer versions of upstream,
RHEL published components. But it's a *lot* of work: I used to publish
"subversion" and HylaFAX updates over  there, before Dag Weiers
stepped away and Repoforge went idle, and the dependency tree was
getting unreasonably long. Same with Samba: Backporting it to RHEL, or
to Scientific Linux which I used to do as a hobby, got out of hand
when it became dependent on a newer version of "gnutls" to support
full Active Directory capability, and replacing *that* would break a
lot of software.

They even publish parallel versions of libraries like openssl, to
support older and newer software. It is useful, but it's not "free as
in beer": it takes time and effort. Basically, I think that your
concerns about RHEL, and in turn Scientific Linux and CentOS, lacking
newer components, is misplaced.

Perl version 6, which you're very excited by, oh boy. I'm staring at
www.perl.org, which states "Perl 6 is a sister language, part of the
Perl family, not intended as a replacement for Perl 5, but as its own
thing". What that means... well, that needs to be left to the
imagination of the developers, because it's apparently not going to
replace *anything* written in Perl 5..

> And if you really, really need something fixed, you are at
> the mercy of RHEL or you  have to ask Nux!, who is a
> blooming genius that this kind of thing.

Or you pay RHEL to spend the time debugging or supporting new
features, which is their business, or you write the code and publish
it and share it under the ideally free software licensing so the
features and fixes get published.  All of that is occurring, with
Fedora and EPEL and with CERN through Scientific Linux. If you're
expecting paid, professional levels of integration, testing, and
support, well, engineers need to eat too.

> In my experience, Nux! will respond to a request in a couple
> of days.  If RHEL does respond, it will be in a couple of years.
> Nux! is the best bet.

Who is "Nux!" ?

ATOM RSS1 RSS2