Re: Pull Request wiki.c.o/AdditionalResources/Repositories

[Tom Sorensen <tsorensen@xxxxxxxxx>]

The rules I went by weren't so cut and dried. EPEL was recommended because it is recommended -- the epel-release package is in centos-extras, packages from it are built to Fedora guidelines, are from Fedora packagers, it endeavors to not overlap upstream, and -- perhaps most importantly -- it is frequently recommended by Red Hat. Yes, I can hunt down knowledge base entries if desired, but that won't be useful to anyone who doesn't have a Red hat subscription.

IUS and ELrepo are recommended because they fit areas where no other repo does, and they do it well. Again, both have excellent packaging standards. IUS provides software that is in base, but doesn't directly replace it (but may obsolete; again... good packaging), updates frequently, etc. There are other repos that do things like offer updated software as IUS does, but not in a way that avoids potentially breaking things. ELrepo provides hardware kmods that a lot of people would be unable to use CentOS without.

The rules for the "Not recommended" category were more clear -- any repos that have been known to cause problems time after time. Replacing packages in the distro with no warning, not updating packages for major known security problems, packaging with missing dependancies, etc. Replacing packages that will break the OS (python, sqlite, etc) is a great way to get on this list.

The rest go to the middle, and I very explicitly decided on alphabetical order to avoid any questions of preference. Some of these repos follow most or all of the "best practices", most don't, and may even stray into the bad practice realm at times. But they haven't garnered a reputation for being either direction yet -- either due to not enough time or users or both.

Tom (Zathrus)

On Wed, Jan 14, 2015 at 7:34 PM, Karanbir Singh <mail-lists@xxxxxxxxx> wrote:

On 14/01/15 23:51, Trevor Hemsley wrote:

> Now as far as the term "Community Approved" goes: I think it's fairly
> accurate and I'm not sure what the objection to it was. We have to have
> a way to say "These repos are ok" and "these suck" and "these suck worse
> than that". The way the page reads at the moment seems to me to strike a
> good balance between providing useful information and avoiding libel!
>

Being able to quantify what good-behaviour might be ( eg. multilib lines
up etc ) not only allows us to measure how good / bad a repo is, it also
gives the other repos a yardstick to work through in order to become good.

I realise that a good repo will do things that are hard to measure  eg.
delta between upstream release of a patch and when it shows up in repo;
but a large bulk of things we should be able to automate I feel.

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc

_______________________________________________
CentOS-docs mailing list
CentOS-docs@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-docs

_______________________________________________
CentOS-docs mailing list
CentOS-docs@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-docs