On Sun, Mar 20, 2011 at 11:56 AM, R P Herrold <herrold at owlriver.com> wrote: > On Sun, 20 Mar 2011, Nico Kadel-Garcia wrote: > >> There are significant components of the upstream 5.6 release which are >> stuck behind the CentOS 5.6 release process, but are now incorporated >> in EPEL 5 components. > > Sad that -- that the dependent partial Red Hat adjunct project > is not compatible with people not using Red Hat's product Whoa, there. Try to be as careful with branding it as our faithful CentOS maintainers are with their branding. It's a *volunteer* effort, much like CentOS (with a much broader set of tasks and goals). It's a very, very useful and worthwhile project, and profoundly extends the useful lifespan of RHEL, CentOS, Scientific Linux, and any other upstream based vendor distributions, and a great testing place for software for the next upstream vendor major releases. It's very much worth cooperating with EPEL, it's compatibility with that upstream vendor is *excellent*, and they're playing it just right. Since the php53 package is in the "upstream vendor" published codelines and updates, there's no reason not to include it in EPEL dependencies. The out-of-date php-5.1 codeline is years old, and the approach is reasonable, and has been used before for samba (which had samba3x), gcc (which had gcc43 and gcc44 in CentOS releases), and bind97 (which is still pending the CentOS 5.7 release). So there's precedent, and a pattern, for including such updates in the upstream vendor's codelines. Unfortunately, right now, it's all blocked in CentOS by the not-yet-announced 5.6 code release. I'd like to see that block lifted on a case by case basis, if feasbile. I've personally tested this php53 package against CentOS 5.5, and it works well and resolves the dependency. Note that Scientific Linux is publishing these updates in a much more up-to-date, rolling fashion. I don't want to switch to that distribution, because the line-for-line compatibility between CentOS and that "upstream vendor" is better, and reassuring to people when I try to get them to switch from one to the other for support reasons. But if I have to, because these updates are blocked for so long, I'll have to take all my testing and bug reports over there. I don't have resources to help yet another distro. > The unpleasantness of reading continual criticism, from those > who will not do the minimal local rebuilds, to use the > packages from a project not affiliated with the CentOS > project, has pretty effectively driven the CentOS core > developers away from this mailing list I *just did* the local rebuilds, and tested them. They work. I want them in the available upstream repositories, which they're not. The "testing" repository is not available by default, and is not generally mirrored. Should it be, by being included in the main websites in their own folder? That would make such "testin" components available to the rest of us. > Niko, I notice you did out post your 'helpful criticism' to > which I respond, on the EPEL list on how to do the workaround > EPEL's policies of not shipping packages competing with Red > Hat's enterprise product. Perhaps they would welcome it > (probably not, as they consciously DO NOT COMPETE with the > parent product) RHEL and Scientific Linux do not have this issue, due to the up-to-date php53 access. CentOS does. It's therefore a CentOS issue, not an EPEL issue, although if you point me to the EPEL list message, I'll be happy to follow up there. > If a person doesn't like CentOS's pace and attention to > shipping durable and 'correct' releases or with different > features (as with EPEL), or want packages faster than CentOS' > rate, PLEASE encourage them to either learn to show some > minimal self-reliance in building, or to not use CentOS as a > base I've said *nothing* against the attention to detail. The pace, however, is becoming problematic. The upstream vendor does not separate the updates by minor release number, and hasn't done that since Red Hat 9. CentOS does not have to emulate. In fact, hey! I just tested a component and announced the results to solve a specific compatibility problem! _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos