This is a public thank you, to whoever wrote the Wiki's for adding 3rd party repositories, ProtectBase and Priorities. Clear, excellent, step by step instructions. I did this late last night and I missed the thing that Priorities is the recommended plugin, so I will change to that, from ProtectBase. :-) Lanny
On 7/26/07, Lanny Marcus mailing-lists@computer2.com wrote:
This is a public thank you, to whoever wrote the Wiki's for adding 3rd party repositories, ProtectBase and Priorities. Clear, excellent, step by step instructions. I did this late last night and I missed the thing that Priorities is the recommended plugin, so I will change to that, from ProtectBase. :-) Lanny
The CentOS team is great. See who contributed to that articular article:
http://wiki.centos.org/Repositories?action=info
Akemi
Information about the epel repository should be added
http://fedoraproject.org/wiki/EPEL
But since it is an immutable page someone with more privileges than I will have to do it.
On 7/26/07, Akemi Yagi amyagi@gmail.com wrote:
On 7/26/07, Lanny Marcus mailing-lists@computer2.com wrote:
This is a public thank you, to whoever wrote the Wiki's for adding 3rd party repositories, ProtectBase and Priorities. Clear, excellent, step by step instructions. I did this late last night and I missed the thing that Priorities is the recommended plugin, so I will change to that, from ProtectBase. :-) Lanny
The CentOS team is great. See who contributed to that articular article:
http://wiki.centos.org/Repositories?action=info
Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
drew einhorn wrote:
Information about the epel repository should be added
http://fedoraproject.org/wiki/EPELBut since it is an immutable page someone with more privileges than I will have to do it.
We should probably wait until they announce that the EPEL repo is released and correct all the missing dependencies first.
<snip>
Thanks, Johnny Hughes
On 7/26/07, Johnny Hughes johnny@centos.org wrote:
We should probably wait until they announce that the EPEL repo is released and correct all the missing dependencies first.
Yes, now if only they marked their packages in some identifiable way that could be easily seen.....
/time to stir the pot a little
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.
Saw some indciations that fasttrack might be CentOS4 only. But there is a Cento5 repo, currently empty
Priority 2
addons csgfs centosplus contrib extras epel
addons exists for CentOS5, but is currently empty. Will anything ever appear here?
contrib and csgfs do not exist for CentOS5. I wonder about csgfs, it sounded interesting but I never took a close look at it. What happened to this stuff, did it vanish or move to a different repo?
I'm assuming contrib is gone forever in CentOS5.
epel exists, but not ready for prime time? I'm assuming that when it is ready it will go here.
Priority 3
atrpms dag dries kbs-CentOS-Extras kbs-CentOS-Misc kde-all kde 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.
Priority 5
kde-unstable-all kde-unstable
Not sure which is less stable testing or unstable.
On 7/26/07, drew einhorn drew.einhorn@gmail.com wrote:
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.
If you ever set up your own local repo, that should be given the highest priority. In that case, you'd better start with a 2 for base etc.
Akemi
On 7/26/07, Akemi Yagi amyagi@gmail.com wrote:
If you ever set up your own local repo, that should be given the highest priority. In that case, you'd better start with a 2 for base etc.
I'm just starting to "play with" priorities, but I actually made mine all multiples of 10 on the first setup to make tuning easier.
Also, I think I've found that if you really want to use the "plus" repo it needs to be the same priority as "base" and "updates".
On 7/26/07, Dave K davek08054@gmail.com wrote:
On 7/26/07, Akemi Yagi amyagi@gmail.com wrote:
If you ever set up your own local repo, that should be given the highest priority. In that case, you'd better start with a 2 for base etc.
I'm just starting to "play with" priorities, but I actually made mine all multiples of 10 on the first setup to make tuning easier.
Great minds think alike. I just sent a message suggesting the same thing.
Also, I think I've found that if you really want to use the "plus"
repo it needs to be the same priority as "base" and "updates".
That could be a problem. Thanks.
--
Dave K Unix Systems & Network Administrator Mount Laurel NJ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
drew einhorn wrote:
On 7/26/07, *Dave K* <davek08054@gmail.com mailto:davek08054@gmail.com> wrote:
On 7/26/07, Akemi Yagi <amyagi@gmail.com <mailto:amyagi@gmail.com>> wrote: > If you ever set up your own local repo, that should be given the > highest priority. In that case, you'd better start with a 2 for base > etc. I'm just starting to "play with" priorities, but I actually made mine all multiples of 10 on the first setup to make tuning easier.Great minds think alike. I just sent a message suggesting the same thing.
Also, I think I've found that if you really want to use the "plus" repo it needs to be the same priority as "base" and "updates".That could be a problem. Thanks.
Well ... actually, having plus lower is a good thing. BUT, it requires you to exclude the packages that exist in Base/Updates if you use the Plus repo.
This is "A GOOD THING" though. You can install anything in plus that is not a duplicate package in base/updates without a problem ... but you can't accidentally install a package that is also in base/updates without specifically excluding it.
On 7/26/07, Johnny Hughes johnny@centos.org wrote:
Well ... actually, having plus lower is a good thing. BUT, it requires you to exclude the packages that exist in Base/Updates if you use the Plus repo.
Sounds like a choice between "some of plus" versus "all of plus", correct?
Great minds think alike. I just sent a message suggesting the same
thing.
Also, I think I've found that if you really want to use the "plus" repo it needs to be the same priority as "base" and "updates".That could be a problem. Thanks.
Well ... actually, having plus lower is a good thing. BUT, it requires you to exclude the packages that exist in Base/Updates if you use the Plus repo.
This is "A GOOD THING" though. You can install anything in plus that is not a duplicate package in base/updates without a problem ... but you can't accidentally install a package that is also in base/updates without specifically excluding it.
Hmm. I'm not sure I understand the easiest way to see the correct solution, to these kinds of problemd. It would be nice if there were a way to see what packages are available, but blocked by packages in higher priority repos, or missing dependencies.
This reminds me of another related question but forgot to ask.
Don't remember exactly which distribution I was running at the time. But I had problems with yum being unable to install certain packages, because issues with complex dependencies were too difficult for it. Someone suggested switching to the "smart" package manager, which was smart enough to downgrade certain packages to resolve dependency issues. Have not seen signs of similar problems so far with yum on CentOS. Has yum caught up with "smart", or are there still some issues here.
drew einhorn wrote:
> Great minds think alike. I just sent a message suggesting the same thing. > > Also, I think I've found that if you really want to use the "plus" > repo it needs to be the same priority as "base" and "updates". > > > That could be a problem. Thanks. Well ... actually, having plus lower is a good thing. BUT, it requires you to exclude the packages that exist in Base/Updates if you use the Plus repo. This is "A GOOD THING" though. You can install anything in plus that is not a duplicate package in base/updates without a problem ... but you can't accidentally install a package that is also in base/updates without specifically excluding it.Hmm. I'm not sure I understand the easiest way to see the correct solution, to these kinds of problemd. It would be nice if there were a way to see what packages are available, but blocked by packages in higher priority repos, or missing dependencies.
This reminds me of another related question but forgot to ask.
Don't remember exactly which distribution I was running at the time. But I had problems with yum being unable to install certain packages, because issues with complex dependencies were too difficult for it. Someone suggested switching to the "smart" package manager, which was smart enough to downgrade certain packages to resolve dependency issues. Have not seen signs of similar problems so far with yum on CentOS. Has yum caught up with "smart", or are there still some issues here.
Well ... I think the problem that you speak of is that yum will ONLY consider the newest package when calculating dependencies.
So, if foo-1.6.4 and foo-1.6.8 are there, it will not install foo-1.6.4 unless you specifically ask for it. It will also try to update foo-1.6.4 to foo-1.6.8 and fail if something requires 1.6.4.
I don't know that smart is "better", but it is different. It can install 1.6.4 as a dependency if needed ... but I don't think it has priorities capability. Which is more important is up to you. CentOS provides yum and supports yum ... is designed to work with yum. Again, it's your box, so try smart if you want ... but I use yum only.
Great idea, But to take it one step further, think I'll use 10, 20, 30, ... That way I'll have room to insert new levels where ever I need them.
On 7/26/07, Akemi Yagi amyagi@gmail.com wrote:
On 7/26/07, drew einhorn drew.einhorn@gmail.com wrote:
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.
If you ever set up your own local repo, that should be given the highest priority. In that case, you'd better start with a 2 for base etc.
Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
--On Thursday, July 26, 2007 12:59 PM -0600 drew einhorn drew.einhorn@gmail.com wrote:
Great idea, But to take it one step further, think I'll use 10, 20, 30, ... That way I'll have room to insert new levels where ever I need them.
I smell an old-time BASIC programmer. ;)
--On Thursday, July 26, 2007 11:52 AM -0700 Akemi Yagi amyagi@gmail.com wrote:
If you ever set up your own local repo, that should be given the highest priority. In that case, you'd better start with a 2 for base etc.
Is there a HOWTO for this (setting up a personal repo) in the wiki? I have a special user for building my own RPM's but have just used RPM to install those in the past.
drew einhorn wrote:
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. Saw some indciations that fasttrack might be CentOS4 only. But there is a Cento5 repo, currently emptyPriority 2
addons csgfs centosplus contrib extras epel addons exists for CentOS5, but is currently empty. Will anything ever appear here? contrib and csgfs do not exist for CentOS5. I wonder about csgfs, it sounded interesting but I never took a close look at it. What happened to this stuff, did it vanish or move to a different repo?
csgfs items are built into EL5 upstream now ... so it is a seperate repo for C3 and C4 ... and in the C5 main repo.
I'm assuming contrib is gone forever in CentOS5.
Unless we need to bring it back for some reason. we decided that we require enough QA and that we have a developer who is responsible for all packages in CentOS ... so, if we have a developer buying off on it, it can go in Extras or Plus.
epel exists, but not ready for prime time? I'm assuming that when it is ready it will go here.
EPEL isn't a CentOS repo ... as all the other ones you have listed above are. It is your box though, so you can put it where you want. I would have it in the other 3rd party repos section though.
Priority 3
atrpms dag dries kbs-CentOS-Extras kbs-CentOS-Misc kde-all kde 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.
Look for an announcement in the not to distant future about a further merger of MOST of these repos (minus the kde ones) into one organization. CentOS will be involved in this organization of RPM repos ... as will (I think) Scientific Linux.
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.Priority 5
kde-unstable-all kde-unstable Not sure which is less stable testing or unstable.
One thing to remember is you can have 99 priorities ... so you can have one for each repo if there is overlap of packages ... that will keep you always getting packageA from the higher priority repo (say dag over kbs-CentOS-Extras as an example).
You can also skip 5 or 10 between repos instead of one, which makes it easy to throw something in the middle between 2 packagesif you need to.
Thanks, Johnny Hughes
epel exists, but not ready for prime time? I'm assuming thatwhen it is ready it will go here.EPEL isn't a CentOS repo ... as all the other ones you have listed above are. It is your box though, so you can put it where you want. I would have it in the other 3rd party repos section though
One thing to remember is you can have 99 priorities ... so you can have
one for each repo if there is overlap of packages ... that will keep you always getting packageA from the higher priority repo (say dag over kbs-CentOS-Extras as an example).
You can also skip 5 or 10 between repos instead of one, which makes it easy to throw something in the middle between 2 packagesif you need to.
I think epel probably goes between 3 and 4, so I think we need the wider for it.
Will repost my final set of priorities once the stream of suggestions dries up.
-
Akemi Yagi -
Dave K -
drew einhorn -
Jim Perrin -
Johnny Hughes -
Kenneth Porter -
Lanny Marcus