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 ...)