CentOS - Mar 2011 - The delays on CentOS 5.6 are causing EPEL incompatibilities

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. In particular, the "php53" package is now
necessary for the "drupal6" EPEL components, due to the long out of
date PHP 5.1 in the default upstream vendor's codebase.

I see that some of these components are available in the "testing"
repository at http://dev.centos.org/centos/5/CentOS-Testing.repo. But
this isn't published with centos-release. fasttrack is. Would it be
reasonable to push these "testing" components over to
"fasttrack"?
Given our "upstream vendor's" policy of making all the updates
available to all the previous releases in their main "channels",
I'm
not sure there's any reason not to present them, at least to the
fasttrack" channel, and migrate them from "fasttrack" to
"updates" as
necessary.

Other components for such fasttrack publication might include bind97,
which some CentOS users have been asking for.
_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos

On 20/03/11 15:23, 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. In particular, the "php53" package is now
> necessary for the "drupal6" EPEL components, due to the long out
of
> date PHP 5.1 in the default upstream vendor's codebase.
>
> I see that some of these components are available in the
"testing"
> repository at http://dev.centos.org/centos/5/CentOS-Testing.repo. But
> this isn't published with centos-release. fasttrack is. Would it be
> reasonable to push these "testing" components over to
"fasttrack"?
> Given our "upstream vendor's" policy of making all the
updates
> available to all the previous releases in their main "channels",
I'm
> not sure there's any reason not to present them, at least to the
> fasttrack" channel, and migrate them from "fasttrack" to
"updates" as
> necessary.
>
> Other components for such fasttrack publication might include bind97,
> which some CentOS users have been asking for.
We've had this discussion before - the fasttrack repository is a rebuild 
of the upstream FasTrack channel, nothing more. Except it's never 
actually been populated for CentOS-5.

The correct place for these packages is in os/5.6 when released. In the 
meantime they have been publicly released to testing for those who want 
early access (fasttrack access if you prefer) or who want to test and 
provide feedback.

Incompatibilities between EPEL and CentOS caused due to the delay in 
releasing 5.6 are a matter for EPEL to resolve. CentOS are doing their 
best to resolve the issue their end by getting 5.6 out as fast as possible.

_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos

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

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

Congratulations


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)

CentOS has an ethic of delivering a product with certain 
quality expectations and testing before it is released (rather 
than inflicting a partially baked release and then streaming 
out curative fixes)

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

my $ 0.02

-- Russ herrold
_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos

I don't see the problem here. I just tested this and it works fine. The 
drupal6 package only requires php 5.2 or greater.

This is out of the drupal6-date.spec file

Requires: drupal6 >= 6.0, drupal6-cck, php >= 5.2

You can get php52 or php53 from the IUS repository.
Install the IUS repo from http://iuscommunity.org/ 
http://wiki.iuscommunity.org/Doc/ClientUsageGuide

Install the yum-plugin-replace package and follow the instructions.

ps. Somewhere there is a dozen people in a Red Hat conference room 
reading this list laughing their heads off. Don't give them more fuel. 
The CentOS team will get 5.6 out soon enough.

On 03/20/2011 11:23 AM, 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. In particular, the "php53" package is now
> necessary for the "drupal6" EPEL components, due to the long out
of
> date PHP 5.1 in the default upstream vendor's codebase.
-- 
Matthew Feinberg
matthew at choopa.com
AIM: matthewchoopa

_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos

On Friday, March 25, 2011 09:55:34 pm Nico Kadel-Garcia
wrote:
> I'm speaking up for our CentOS repackagers here. That kind of
> bootstrapping takes cycles and practice, and double checking. In
> theory, they could. Our CentOS rebuilders have exposed a few
> dependencies for which the SRPM's are not published (and which our
> favorite upstream vendor is fixing them, but they *don't have to!!!*.
> That's not part of a GPL license, it's just good free software
> practice.)
Let me speak up for our CentOS devs too, as the upstream doesn't have to
bootstrap in this way.  Their bootstrap dates from Mother's Day.

Fedora likewise; they have a previous version, and rolling binaries that are
pretty well depsolved already.  The rebuilders are the ones who have it more
difficult, as they have to reproduce a build sequence from a known snapshot
point (the last public beta).

And the *distribution* as a whole is not covered by the license you might think
it is.

Les, the upstream source RPMs aren't even the "source source" for
the upstream build; SRPMS are just a by product of the build of the binaries
from source in an SCM (managed by Red Hat's koji), and in theory, given the
same identical environment that built the upstream binaries they will re-build
to the same binary.  The environment is the hard thing to replicate, since it is
a moving target, and each build changes it slightly.  It's questionable if
upstream could exactly replicate it from their own source RPM's without
significant effort (that is, outside of koji).

To their credit they fix those sort of bugs in due time, but as mentioned they
are not bound by any license to do so, since the binary build environment
isn't part of the 'source code.'

Karanbir and Johnny have both posted at length about this issue; Russ as well.

What's interesting is the length of time it's taking SL as well to get
4.9 and 5.6 out in GA, as well as CentOS with a GA for 5.6 and 6.0.  It seems to
be pretty soon due, at least 5.6.

As it stands, SL has a GA 6.0, and CentOS has a GA 4.9.  I like many others am
waiting for that middle piece, a GA 5.6.  But I'd rather have it correctly
done than quickly done if I have to choose.

On Saturday, March 26, 2011 02:53:19 pm Les Mikesell
wrote:
> Does an 
> rpmbuild --rebuild of one of the packages in question on a stock RH system 
> create a binary that would fail the CentOS QA?
This is the core of the question.  As I don't have an RHEL 6 system
available to try, I can't directly answer that.

The answer is 'it depends'.  But you still miss the issue; the buildroot
repository is the binary tree built against, and it could contain binaries that
are different from the shipped RHEL system's binaries.  Of course,
that's with mock, which makes it easier to make something that is not
self-hosted; it also makes it possible to build multiple versions of systems on
a single buildhost running yet a different version.

Straight rpmbuild --rebuild may very well fail with missing build dependencies,
which you would then have to go spelunking for in non-RHEL repositories (but
they're out there, or SL6 wouldn't be built at all, now would it?).  You
have the exact source code used to build the package you have installed; you may
or may not have all of the same versions of the dependencies that your binary
package actually was built against.

The question can be distilled as 'is RHEL self-hosting' to which the
answer has been for a while 'No, and that isn't a primary goal of
RHEL.'

"Why not?" would be a reasonable question right about now.

To use an example I work with, current Ardour 3 source code out of subversion
(Ardour 3 is in alpha test, and is not released) cannot be compiled against just
any version of the JACK development headers and libraries; to get a working
executable, you have to compile against a specific version of the jack-devel
package; but the built binary can run with any recent version of the JACK
library.  An Ardour 3 binary could be built and shipped that would work fine
with the current JACK 1.96 but was built with 0.120.1 (which is the specific
version required for the build to be successful).  I would give you a link, but
the current 'ardour-dev' archive is only available to members of that
list.

The point being, there are likely reasons other than carelessness or
obfuscation-ness that a package might be built against development headers and
libs that are different from the shipping versions (but with compatible sonames,
perhaps), or maybe built with a different toolchain (compiler, linker, etc) than
the shipping version of those tools, perhaps in order to just get the package to
build; it will run fine with the shipping binaries, but may not build with them.
And it may be a niche thing, where other packages in the distribution won't
build with that particular toolchain....

I'll finish by pointing to the following resources for learning more about
this (and I'm just throwing these out, I've not thoroughly checked
everything said in these pages, but notice who is posting in some cases):

http://adsm.org/lists/html/Veritas-bu/2010-07/msg00135.html
http://www.redhat.com/archives/rhl-list/2004-January/msg02812.html
http://www.redhat.com/archives/taroon-beta-list/2003-September/msg00038.html
http://www.redhat.com/archives/nahant-beta-list/2004-November/msg00072.html
http://www.redhat.com/archives/nahant-beta-list/2004-November/msg00073.html
http://www.redhat.com/archives/nahant-list/2006-July/msg00059.html
http://www.redhat.com/archives/taroon-list/2004-March/msg00249.html
http://www.redhat.com/archives/taroon-list/2004-March/msg00261.html
http://www.redhat.com/archives/nahant-list/2006-May/msg00266.html
http://www.redhat.com/archives/nahant-list/2006-May/msg00264.html
(side note on that last one.... there was and maybe still is a 'Cisco
Enterprise Linux' build......reference:
http://fr2.rpmfind.net/linux/RPM/sourceforge/p/project/pi/pipeviewer/OldFiles/pv-0.8.6-1.x86_64.html
)
http://www.redhat.com/archives/taroon-list/2005-March/msg00222.html
http://www.redhat.com/archives/taroon-list/2005-March/msg00228.html
http://www.redhat.com/archives/nahant-list/2006-May/msg00273.html

There are more.