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]
