On Sun, Mar 20, 2011 at 11:56 AM, R P Herrold <herrold@xxxxxxxxxxxx> 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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
