On Thu, 29 May 2008, Ralph Angenendt wrote: > Only if that person also wants to support that on the #irc channel and > can explain why we support one type of vserver and don't support the > other :) a bit harsh -- the wiki article as written is to address _broken_ vserver matters http://wiki.centos.org/TipsAndTricks/BrokenVserver I worked a bit on wordsmithing part of that, hoping for the emergence of a 'grafted on' vserver which was respectful of what I (and I think most of us) would consider a 'CentOS' server, with the tests of the section: You are saying I was lied to and mislead? Yes, a true CentOS installation has a CentOS kernel, the CentOS centos-release package, the CentOS yum package, and no modification or additions to the contents of /etc/yum.repos.d/. All dependencies will be satisfied, and except for configuration files (see: man rpm), an $ sudo rpm -Va will run silently except for expected configuration file changes. A true CentOS system also may be freely updated at any time. We add this requirement as security fixes also issue asynchronously. One indication that there may be a problem is that the rack hosting vendor offers CentOS 4.X (where X is a digit), rather than CentOS 4, and so forth; the CentOS team (and indeed the upstream distribution stabilizer) do not permit 'holding back' at a non-current, prior 'point' version, and still representing the product as the 'genuine' article. ------------------------------------------------------------- So long as any sub-set install has addons which is packaged, satisfies all dependencies [and thus is without material excludes= holdbacks], and does not break rpm -V on packaged CentOS core items (or the subsystem the inquirant is having issues with), I've no problem with discussing and trying to support it in IRC We have people wander in with hand compiled php, MySQL AB binaries, and config file edits; they chose to fork and are on their own, until they revert to something CentOS ships. So long as a misbehaving package is ours, and not tampered with, I think we have some obligation to respond in IRC, and in the bug tracker; but contrarywise, when the packages from others, I certainly have no compunction about referring the person back to the packging source, where (one assumes) it is known as to quirks and supported. -- Russ herrold