[CentOS-docs] Pull Request wiki.c.o/AdditionalResources/Repositories

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 at karan.org>
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 at centos.org
> http://lists.centos.org/mailman/listinfo/centos-docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150114/4216a23d/attachment-0002.html>