Which extra repositories can be used with CentOS 6?
Well, just like you could use any RHEL5 repo with CentOS 5, any RHEL6 should be compatible with CentOS 6. If you're looking for names, this can be useful : http://wiki.centos.org/AdditionalResources/Repositories
2011/7/12 Edson - PMSS edson.amaral@saosebastiao.sp.gov.br
Which extra repositories can be used with CentOS 6?
-- Edson D. Amaral Pref. Mun. de São Sebastião - SP
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Eric Viseur wrote:
Well, just like you could use any RHEL5 repo with CentOS 5, any RHEL6 should be compatible with CentOS 6. If you're looking for names, this can be useful : http://wiki.centos.org/AdditionalResources/Repositories
Beside those there should be these also: virtualmin pidgin playonlinux virtualbox
On their respective domains, but I am yet to install any C6 system in order to check it.
Ljubomir
On Tue, Jul 12, 2011 at 03:01:09PM +0200, Ljubomir Ljubojevic wrote:
virtualmin
Perhaps we can avoid advocating repos that stomp all over base and replace core components?
John
On Tuesday, July 12, 2011 09:09:36 AM John R. Dennison wrote:
On Tue, Jul 12, 2011 at 03:01:09PM +0200, Ljubomir Ljubojevic wrote:
virtualmin
Perhaps we can avoid advocating repos that stomp all over base and replace core components?
Perhaps they could be listed, with a note that says they do that?
For example, a repo with an up to date KDE would have to do that, and I'm looking for that particular thing. I'd prefer to have EL6 on one box, but KDE 4.6 at least, and if that means a few other things have to get 'stomped on' then so be it. And, yeah, I'm probably capable of rolling that myself, if need be, for my own private use.
Even if that means a separate wiki page for 'repositories that stomp all over core deps.' With a caveat that using these repos would mean potential lack of help in the main centos list/forum/IRC and that users of said repo would probably need to go to that repo's list/forum/IRC for any meaningful support.
On Tue, Jul 12, 2011 at 09:24:54AM -0400, Lamar Owen wrote:
Perhaps they could be listed, with a note that says they do that?
They will still end up here and on IRC wondering why their system is broken at some point. The wiki is populated with repos that should be flagged as "This repo will cause tears of impotent rage" or just removed.
For example, a repo with an up to date KDE would have to do that, and I'm looking for that particular thing. I'd prefer to have EL6 on one box, but KDE 4.6 at least, and if that means a few other things have to get 'stomped on' then so be it. And, yeah, I'm probably capable of rolling that myself, if need be, for my own private use.
You're capable of supporting your own boxes :)
Even if that means a separate wiki page for 'repositories that stomp all over core deps.' With a caveat that using these repos would mean potential lack of help in the main centos list/forum/IRC and that users of said repo would probably need to go to that repo's list/forum/IRC for any meaningful support.
They'll still end up in #centos if history is any past indicator. The repos in the wiki that horse-stomp base are, for the most part, listed as such; wording needs to be quite a bit stronger. In a different color and point size. Flashing might be useful as well.
But I'd really be happy to not see them recommended here unless the person making the recommendation takes ownership of all support issues that the user has from said recommendation. That seems fair :)
John
On Tuesday, July 12, 2011 09:46:21 AM John R. Dennison wrote:
They will still end up here and on IRC wondering why their system is broken at some point.
Indeed. If history is any indicator, even changes in the base repos will do the same. (recent history, even, like as in less than an hour ago.....)
The wiki is populated with repos that should be flagged as "This repo will cause tears of impotent rage" or just removed.
Which reminds me of a question.... but which I'll ask privately.
And, yeah, I'm probably capable of rolling that myself, if need be, for my own private use.
You're capable of supporting your own boxes :)
Well, to a point I could support them myself. It is in fact easier to roll a package set than it is to support said package set (which is why it would be for my private use, as I'm not willing at this juncture to both roll a package set *and* go back into the package set support business; been there, done that, got the bruises to show for it). It would be an opportunity to learn more about KDE, though. Perhaps more than I want to know.
They'll still end up in #centos if history is any past indicator.
Yep.
But I'd really be happy to not see them recommended here unless the person making the recommendation takes ownership of all support issues that the user has from said recommendation. That seems fair :)
More than fair. And that would be something I'd be willing to do if I do find someone else's repo that does modern KDE; if I don't have to spend the time to roll the package set, leaves more time to help support said package set.
From: John R. Dennison jrd@gerdesas.com
But I'd really be happy to not see them recommended here unless the person making the recommendation takes ownership of all support issues that the user has from said recommendation. That seems fair :)
Maybe the yum priorities plugin paragraph in the wiki page should appear in flashing bold... I would even make its default installation mandatory...
JD
John R. Dennison wrote:
On Tue, Jul 12, 2011 at 03:01:09PM +0200, Ljubomir Ljubojevic wrote:
virtualmin
Perhaps we can avoid advocating repos that stomp all over base and replace core components?
I just added several that are on my list. Virtualmin repo is where Webmin rpms are located. I avoided giving any links, so who ever decides to check it out will have to read their web site and hopefully will understand his own actions.
Given that most of the noobs try to compile packages from tar's, my approach is actually more benign than what they would do on their own. And majority of users will not be interested in Virtualmin anyhow. But I will be extra careful about this.
In next month or two I will raise possibility to (in some safe form) add Priority lines in yum repo files, and to start a campaign in educating CentOS users in safe ways to use existing repositories to avoid compilations of packages on their own.
Ljubomir