SCIENTIFIC-LINUX-USERS Archives

June 2008

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:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Fri, 20 Jun 2008 12:28:16 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (74 lines)
Hi,
EPEL is not one of our convenience yum repositories, so in order for 
someone to use it, they have to manually setup the epel yum repository. 
  So just because it's in EPEL doesn't mean that it's convenient for 
people to install.
Why don't we have it as one of our convenience yum repos?
The easiest answer is that some packages in EPEL conflict with packages 
in our convenience repo's (dag and atrpms).  So if we put in epel, 
people would turn both epel, dag, and atrpms on, and then their system 
would get this really weird mess.
Now that I think of it, maybe if we put priorities in the yum-conf 
files, had yum-conf-epel require yum-priorieties, and have dag and 
atrpms have a higher priority than epel.

Why am I favoring dag and atrpms above EPEL?
First off, dag and atrpms have been around longer, with a longer track 
history.  So we know what they are going to do.
Second off, dag and atrpms are more in line with our goals than EPEL is. 
  There are some packages that dag and/or atrpms have in them that will 
never make it into fedora and RHEL, and hense, EPEL.

So which maintaines their rpm's better, EPEL or SL?
I honestly don't know.  It's probrubly on a case by case basis. 
Graphviz we are moving up to version 2.18, while they are at version 
2.12.  But they might change next month, I don't know.
R: EPEL does a new R every six months.  I try to get all the versions of 
R in Contrib, and put the newest on into the release whenever we have one.
I haven't checked beyond that.

I guess I should end this, and just answer your question.
graphviz stays into SL5.

Troy

Konstantin Olchanski wrote:
> Troy - some of our machines are configured with the EPEL repository
> and we have observed conflicts between SL and EPEL graphviz
> packages. With graphviz available from EPEL, is it important
> to have it as part of SL5? Which version is better maintained?
> 
> K.O.
> 
> 
> On Fri, Jun 20, 2008 at 11:44:03AM -0500, Troy Dawson wrote:
>> Hello,
>> I am trying to update the version of graphviz that will be in SL 5.2.
>> There is a minor bug in the current one, and I figured we'd just update
>> to the latest.
>> Well, as some have noticed, we got some new modules, and some of the old
>> modules didn't build.  I think I can fix up everything except for
>> graphviz-lua and graphviz-ocaml
>>
>> Now, here's the odd part.
>> Our past rpm didn't have these rpm's requiring lua and ocaml
>> respectavely.  And the bigger problem is that lua and ocaml aren't even
>> in Scientific Linux, they are in Dag's repository.
>>
>> So, the question is this.
>> Did anyone use these particular packages?
>> And if you did, did they work without adding packages from Dag?
>>
>> I would like to just take them out, since it looks like it's a mistake
>> that we have them in.
>>
>> Any objections?  Problems?
>>
>> Troy

-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________

ATOM RSS1 RSS2