|
On 01/15/2015 01:09 AM, PatrickD Garvey
wrote:
Yes, it is. Some people need newer versions for applications than what the distro can provide. Other need complementary stuff which the distro or better said RHEL is not willing or not able to provide.On Tue, Jan 13, 2015 at 10:04 AM, Karanbir Singh <mail-lists@xxxxxxxxx> wrote:On 01/09/2015 11:49 PM, Tom Sorensen wrote:KB -- I made those changes several months ago (Sep/Oct I believe), with discussion in IRC. This was after a spate of people in the main channel having issues with Atomic (there's a name that's going to end up causing problems...) and the continued use of RPMForge/RepoForge, with no indication that they're really really bad. As well as the recognition of the reality that there are a very few repos that are frequently recommended (and, in the case of EPEL, now easily enabled in CentOS).I think we should do a bit of work and find a tangiable set of standards that a repo needs to meet in order to be 'endorsed' or rated at a certain level. Because at the moment it does seem to add value to a repo or two over others, based on personal opinion. I am willing to write code to do this validation, but were going to need a set of good rules to implement. regards and thanks - KBMaybe it isn't code that needs to be generated. I obviously wasn't around for any IRC discussion of this page and its implications. I don't imagine there is any sort of log of that discussion I could review. Rhetorical questions and comments: Is it true some of these repos exist because CentOS wasn't adequate for some particular purpose, but someone thought they could provide a parallel resource to easily install additional software? [...] Right. Some repos lead to problems similar to:From Tom's comment I infer there was a need to warn people away from using some repos that were consuming significant resources to help folks who had trusted them. Aug 28 14:27:15 <TheAlien> hey there, im having trouble updating packages on my server. yum update gives a long list of needed updates and sumarises 'Install 3 Package(s) / Upgrade 132 Package(s) / Remove 1 Package(s)' but then says 'package mysql-5.5.25-1.el5.remi.x86_64 (which is newer than mysql-5.0.95-5.el5_9.i386) is already installed' -- Aug 28 14:27:24 <TheAlien> plus several messages like 'file /usr/bin/mysqlaccess from install of mysql-5.0.95-5.el5_9.i386 conflicts with file from package mysql-5.5.25-1.el5.r Others simply are no longer properly maintained, for instance still shipping older versions of applications which have known vulnerabilities. [...] It also appears that somehow Fedora's efforts have been mutually beneficial. Yes, they have but this has nothing to do with the wiki page we speak about. Incidentally EPEL aims to a high standard so as to make it suitable for an enterprise-grade distro which CentOS aims to be and that is why we recommend to all others packagers to follow similar rules ( when possible and if they make sense, of course ). However this is by no means a requirement that must be met in order to have a 3rd party repository listed in the CentOS wiki. I can only concur with what John has said. You are looking for problems to fix where there are none. 3 months ago Tom has made a great job in cleaning the page up ( and several of us assisted him when he asked for opinions ) and - AFAIK - its current shape expresses the views of most of the regulars who provide help via the various CentOS support channels. If and when needed we modify the page but as it is now it is completely satisfactory for its purpose. Even if the feelings of some people get hurt by our opinions about the quality of their work ( i.e. of the packages they provide ).With these thoughts as background for my thinking, my brainstorm is that the Special Interest Groups and spins may be the path to solving the need to have additional non-CentOS resources and know they are sufficiently cooperative. Proposal: The Third Party Repositories section should not list any other repositories, but should only note there are difficulties in making several independent repositories safely usable and give a thorough explaination of what has happened in the past without naming names. |
_______________________________________________ CentOS-docs mailing list CentOS-docs@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-docs
