[CentOS] Centos 6.3 - which repos to use?

Sat Jan 26 03:59:15 UTC 2013
Bry8 Star <bry8star at yahoo.com>

Received from Nikolaos Milas, on 2013-01-25 10:05 PM:
> On 25/1/2013 11:28 μμ, Leon Fauster wrote:
>> not the CentOS(-Team) but the user it self is risking this …
> True. CentOS/RHEL are using the least-risk policy by rarely
> updating packages, except for serious bug/security fixes and that
> helps provide peace of mind from the base OS.
> Yet, I have come to believe that Systems Administration is not
> trivial in terms of decision-making; in fact, one could say that
> it may be a highly philosophical (!) job.
> You must balance availability of features, stability,
> manageability, security, package dependencies,
> application/service deployment and maintenance and more.
> Experience, knowledge and a thoughtful attitude will hopefully
> help find a "golden section" between all these through time on a
> per case-basis.
> No systems are identical. The sysadmins have to *study* their 
> environment and needs and then design the proper solution on each
> case.
> As a simple example, if there is a requirement to run OpenLDAP
> *as a server* on a CentOS OS, the sysadmin MUST find *how* to run
> the latest version (which is the only "approved" one for OpenLDAP
> server deployments by the OpenLDAP project). Deploying OpenLDAP
> using the packages available by either CentOS 5 or 6 repos is
> unacceptable.
> 2c,
> Nick
> _______________________________________________
> CentOS
> mailing list CentOS at centos.org 
> http://lists.centos.org/mailman/listinfo/centos

Thanks Nikolaos/Nick.
Very accurate, from my applied case/scenario as well.

Different demand and functionality requirements causes different
types of settings for different repos.

And on some boxes where i want to deploy/apply/expect latest apps
and services or functionality, (like one of them you've mentioned is
OpenLDAP), CentOS requires me to do massive modifications.

I find it very very annoying that, CentOS lacks STABLE+last
releases. It is not only CentOS, ther Linux as well. But this RHEL
close/derivative, is very very behind.

I needed & still need to do vast amount of
etc very careful implementation & management on all .repo files.
And on top of that, YUM, understands only (the last) one line of
"includepkgs=..", "protect=..". :-(

If it(YUM) were to understand multiple of those config
options/lines, then, different type/category of apps/tools could
have been added, copy/pasted or moved/placed easily on different
channels of different related repo, based on their "priority" sequence.

And YUM need to have a feature to analyze a user specified/given
app. IF, yum were to have a feature to analyze current priority,
include, exclude settings, and then show/indicate what include,
exclude need to be set for an user-specified or pre-specified
last+stable app/tool, then such would have been very helpful. Yum
need to analyze all deps/libs related to that pre-specified app.

And, may be even a better chroot type of app/system should be
developed & exist in CentOS/RHEL, to easily try those STABLE+last
releases, effectively, so that service based on those can be easily
used, even on a 128 MB based box.

CentOS webpage/site should also show to all users, some example of
using multiple repos and how to implement effective includepkgs,
exclude, priority etc directives properly for some certain last &
STABLE app(s) (which is by default not in CentOS), so that others
can understand the pattern, or have a pointer for them.

Just mentioning about, that, there is such things called
"includepkgs=...", "exclude=..." ad now go do it yourself (and sorry
no example), obviously does not help that much to users, and its
CentOS's loss as well, users go away to other distros, and
ultimately many of them are lost in the jungle.

-- Bright Star (Bry8Star).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20130126/f48dac94/attachment-0004.sig>