[CentOS] Dag's comment at linuxtag

Thu Jul 2 01:36:23 UTC 2009
Michael A. Peters <mpeters at mac.com>

Radu-Cristian FOTESCU wrote:
>> Buildlogs are available from:
>>     http://packages.sw.be/comix/_buildlogs/
>> I hope you come back and tell me what was your problem.
> I have to be back on my continent before addressing this issue.
> So far, I can see that the build of Comix seems to have been done
> by Dries, and that it was successful in April 2009.
> I am pretty much sure I can prove it *won't* compile on any EL5 clone
> with the officially available versions of:
> BuildRequires: python, python-imaging, pygtk2-devel
> I am not sure what mushrooms were installed on the build machine.
> It *doesn't* build with:
>   pygtk2-devel-2.10.1-12.el5.i386
>   python-imaging-devel-1.1.5-5.el5.i386
> Which is whatever EL5 has.
> I can see that RF has a slightly newer version of 
>   python-imaging-1.1.6-2.el5.rf.i386
> but as long as the SPEC file doesn't require a newer version
> than 1.1.5, nor does the tarball's Makefile, I *don't* pull
> updates from RF.

I don't find updating something like python acceptable.
If I have to update the CentOS provided python, then the newer python 
had better be packaged as a compat package that does not conflict with 
the vendor supported version of python, or I don't want it.

I'd run Fedora or Ubuntu if I wanted to break RHEL compatibility.

If the issue of it building is the python version, then it should be 
backported or not included in the repo. That's my opinion.

I've had enough stuff I build on my system break when an EPEL package 
updates the version (IE xine-lib which had several updates to version in 
past 6 months or so), updating versions is not something an enterprise 
distribution should do without careful thought, and neither should third 
party general repos.

Third party specific repos (IE a repo dedicated to newer php) - that's a 
different story, and requires the user add excludes to things like base 
and updates yum configuration. But a general purpose repo that provides 
add ons should not update base packages.

How it interacts with epel I don't really care about, but it should not 
update vendor packages, and anything that requires an updated vendor 
package will be broken on yum configurations that protect the base install.

While maybe not HFS compliant, it should be possible to build a newer 
python in, say, /opt/rpmforge and rpmforge (or whatever) packages that 
specifically need that newer python can call /opt/rpmforge/bin/python 
full path.

Most library packages can have updates available with a simple 
foo-compat package name, devel packages sometimes conflict but you can 
usually leave the devel packages in repo and let them be installed by 
mock during build of software that needs the alternate library version.

There are solutions for most things that do not require replacing a 
vendor supplied package. Hell, even gnome can be updated into /opt if 
you wanted newer gnome but stability of centos base (probably would take 
a hell of a lot of compat packages though ...)