SCIENTIFIC-LINUX-USERS Archives

March 2015

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:
Akemi Yagi <[log in to unmask]>
Reply To:
Akemi Yagi <[log in to unmask]>
Date:
Fri, 27 Mar 2015 09:15:05 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (14 lines)
On Fri, Mar 27, 2015 at 9:02 AM, Tim Kanuka <[log in to unmask]> wrote:
> I think having a EPEL mirror in the way described by Steve is an excellent idea. It exactly parallels my own requirement (and I suppose any site's requirement) of managing updates to many machines. The only way to guarantee that you are not going to break something with an update is to test your applications on an updated *test* environment. The only way to guarantee that your *production* environment is updated in the same way as the *test* environment is to have a mirror repo that is not changing unexpectedly.

I'd like to note that EPEL is not the only 3rd party repository. :-)

In the case of ELRepo, it was also debated when to release the
7.1-based packages. They are all built against RHEL 7.1 like EPEL's.
One thing that is different from EPEL is that ELRepo's el7.1 packages
that are _not_ backward compatible will not install on systems < 7.1.
yum will complain. My understanding is that EPEL packages do not have
such 'Requires'.

Akemi

ATOM RSS1 RSS2