On Fri, 20 May 2005, Bryan J. Smith <b.j.smith at ieee.org> wrote: > From: Johnny Hughes <mailing-lists at hughesjr.com> > > > 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 at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]