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 includepkgs=... exclude=... priority=... protect=... 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>