Here's how I set up my repository priorities, with some questions, and request for comments on whether there are better ways of doing things.  I'm running on CentOS 5, some of the repositories do not exist, some exist but are empty, etc.

Depending on whether I am in production, test, or development, various subsets of these may be enabled/disabled. Priority 1     base     updates     fasttrack          These all need to be at the same level so they can replace one another.

<br>    <br>    Saw some indciations that fasttrack might be CentOS4 only.  But there is<br>    a Cento5 repo, currently empty<br><br>Priority 2<br><br>    addons<br>    csgfs<br>    centosplus<br>    contrib<br>    extras

<br>    epel<br><br>    addons exists for CentOS5, but is currently empty.  Will anything ever<br>    appear here?<br><br>    contrib and csgfs do not exist for CentOS5.  I wonder about csgfs, it<br>    sounded interesting but I never took a close look at it.  What happened

<br>    to this stuff, did it vanish or move to a different repo?<br><br>    I'm assuming contrib is gone forever in CentOS5.<br><br>    epel exists, but not ready for prime time?  I'm assuming that<br>    when it is ready it will go here.  

<br><br>Priority 3<br><br>    atrpms<br>    dag<br>   

dries<br>   

kbs-CentOS-Extras<br>   

kbs-CentOS-Misc<br>   

kde-all<br>   

kde<br>   

rpmforge     There is a lot of overlap here.       Have not yet taken a close look at each one.     Several of these have merged into rpmforge.     Which ones should still be used with CentOS5.

kde does not distinguish between CentOS 4 or 5     which sounds bogus.      Priority 4     kbs-CentOS-Misc-Testing     kde-testing-all     kde-testing     Hope I never need to dig this deep into the bleeding edge.

<br><br>Priority 5<br><br>    kde-unstable-all<br>    kde-unstable<br><br>    Not sure which is less stable testing or unstable.<br><br>-- <br>Drew Einhorn