Re: mplayer repository for CentOS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, 20 May 2005, Bryan J. Smith <b.j.smith@xxxxxxxx> wrote:

> From: Johnny Hughes <mailing-lists@xxxxxxxxxxxx>
> 
> > Just for the record, using the Fedora Core library on CentOS-4 can be
> > problematic (and even DAGs repo, for that matter) ... in that both can
> > overwrite base CentOS libraries.
> 
> I find as long as I align the versions correctly, and _only_ tap Fedora
> Extras and Livna.ORG (and _not_ Fedora Core), I haven't had an issue.

What is your plan when Fedora Extras is doing Fedora Core 5 and Fedora 
Core 6 only and you'r stuck with RHEL4 systems ? If you can rely on Fedora 
Extras now it's because you don't have RHEL2 or RHEL3 machines I guess.


> > Karanbir Singh is working on a rebuild of FC Extras that uses
> > functionality already in CentOS-4 and doesn't upgrade any packages
> > (unless required) that are part of the base centos.  Since FC is not
> > CentOS, and there are differences in some libraries, I would
> > recommend Karanbir's repo over FC Extras (for CentOS-4).  I don't
> > have the address of this site handy right now...I'm sure someone does.
> 
> One thing I'm tiring of is the inconsistency between FC/RHL and RHEL.
> It's one thing that is looking better about SL and NLx every day.
> I'm waiting to see what Novell does with SL 10.x and NLx 10.

The inconsistency is (partly) the result of not caring about backward 
compatibility in SPEC files (but also userland utilities and RPM itself).

Whatever they improve now in RPM, we will have to live with RPM from 
RHEL2, RHEL3 and RHEL4 for a long time. So whatever new features are being 
used in SPEC files, if Fedora Extras adopt those, you lost support for 
rebuilding Fedora Extras stuff. Things like that already happened, try 
compiling Fedora perl packages on RHEL3 and you'll see what I mean.

Fedora == Development, at a fast pace, not looking back, it contradicts 
with the reasons you go with RHEL.


> > Just be careful when using any external repo, as it can replace things you
> > don't want.
> 
> Exactly.

Bryan, that's more a apt/yum issue than it is a repository issue. If you 
think repository maintainers should divide their repository in all 
possible permutations of what people might want (and what 
cross-requirements exist between these repositories), you have not 
maintained a big repository. Believe me, this functionality should go into 
Yum (apt has hte functionality, but apt is dead anyway). Smart can do it 
and if you're a RHEL4 user, I would recommend Smart as it allows you to 
specify what you want and don't want from whatever repository you add.

It should go into Yum, because only the user knows what policies it 
requires for their business and it gives much more flexibility.

--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux