[CentOS] Centosplus & CentOS Extras, Enlarge your tent

[Lamar Owen]

On Sunday 12 March 2006 09:14, Jim Smith wrote:
> The problem with some of the 3rd party repos that overwrite system
> files, (look at the example i gave of one repo even wanting to
> overwrite selinux) is that the maintainers live in a cuckoo world and
> do not respond to feedback. What is the point of replacing core
> system files if all you need is mythtv?

Ok, let me give you a scenario or three.

Suppose you want, say, GNUradio on your CentOS box.  (I use this example 
because I use GNUradio on my CentOS box....)

GNUradio requires a significantly more recent version of SWIG than ships with 
CentOS 4.  Ok, if you are going to package a repo for GNUradio (which I plan 
on doing at some point) you WILL have to replace the existing SWIG or make a 
parallel SWIG for GNUradio.  What can you do otherwise?  There are also other 
items that GNUradio will require; fortunately the big one, FFTW 3, isn't part 
of the base CentOS, and that particular library has to be built with 
nonstandard options.

Second scenario: you want Plone 2.1.2 on Zope 2.8.  Ok, this means you need 
Python 2.4.  CentOS 4 ships Python 2.3.4, and the Zope build will die if you 
try it on that Python.  What do you do?  You can either replace the core 
Python, or make a parallel Python; neither task is easy (on the surface, a 
parallel Python seems easy; in practice is is not, and can require large 
patches to programs that require the parallel version....).  ATrpms has a 
Python24, but then you need the rest of the ATrpms repo.....

Third scenario: you want the version of Kstars that does telescope control 
(see my .sig for why I might want this).  This requires a much later KDE than 
the 3.3.1 shipped with CentOS 4.  The later KDE builds REQUIRE a LOT of core 
library changes, touching over half of the distribution.  Rex Dieter has done 
an amazing job with KDE-RedHat for EL4, and, frankly, that is a thankless 
job, because if you choose to use KDE-RedHat you can break many many many 
other packages and repos that rely on the CentOS-default KDE 3.3.1.  I have 
found Rex to be very responsive to repository issues from first-hand 
experience, and the quality of the packages seems as good as most others.  
No, they are not 'blessed' by the CentOS core, and that's OK.

 Axel Thimm (who also has a very thankless job, having taken on the 
maintenance of some quite cutting edge software and trying to make it work 
with Scientific Linux 4 (the packages for which work fine on other EL4 
distros, but keep in mind that Axel is packaging for and with SL4, not CentOS 
4)) is packaging mythtv, which requires several extra libraries, and not 
charging you a penny for it.  If you can get that package set to build 
without all the other changes that have to be made, then by all means go for 
it.  In the case of mythtv, ATrpm's packages are built within the framework 
of the rest of ATrpms; thus, those mythtv packages (rebuild mythtv from 
source to see why) require the rest of ATrpm's infrastructure; does it make 
any sense any other way?

But it is rude and off-base, in my opinion, to call a dedicated third-party 
packager 'cuckoo' simply because they do it differently, or because they HAVE 
to replace large parts of the core distribution to get their packages to 
work.  The CentOS base package set is showing its age, as are all other RHEL4 
rebuilds, and RHEL4 itself; this is one of the downsides to using an 
'Enterprise' Linux.

Third party repository interaction is an old problem, and one that is not 
going to go away anytime soon.  If you choose to use a third party repo, and 
it breaks your box, you get to keep the pieces.  Unless you are willing to 
pay someone to maintain the exact set of packages that you want, or are 
willing to maintain them yourself, then you really don't have any room to 
complain to a great degree; that is, before you enable that third-party repo 
file, you had best find out what it is going to do to your system, and then 
you NEVER just 'yum -y upgrade' while a third-party repo is enabled, 
otherwise you get what you get.

This means that sometime you have to choose which set of third party packages 
you want, and go with that set, ignoring all others.  The PlanetCCRMA 
packages for FC are along those lines; you want those features, you pretty 
well must use that repo exclusively.  KDE-RedHat is also in that category, 
since so many packages have to be changed to get KDE 3.5.1 (the current 
release) working.  ATrpms, because of some of the software being packaged, 
must also do this.  DAG and the rest of the RPMforge set likewise; I ran a 
machine once with FC2, DAG, ATrpms, and KDE-RedHat all enabled at the same 
time, and it was not pretty.  But since I chose to enable all three, I got to 
keep the pieces and I had to fix the problems, which were many and 
continuous; that machine happened to be my main work laptop, which is now 
running CentOS 4 with KDE-RedHat and Karanbir's Extras (which for the most 
part mixes OK with KDE-RedHat, as long as I don't pull over a KDE 
3.3.1-packaged extra from Karanbir's Extras).

Now, as to why someone would want to 'Fedorize' their CentOS rather than just 
run Fedora, well, there are some instances where such a thing is useful.  
Again, I use the Kstars example; one might say 'well, why not just run 
Fedora' to which I would answer 'I don't want to completely reinstall 
machines every six months; besides, KDE-RedHat exists and works fine, and I 
get the base stability of the CentOS kernel and glibc, and I then can 
leverage my standardization on CentOS 4 for all my servers'.  I have been on 
the Fedora roller-coaster, and I don't like it.  Although I may have to deal 
with the CentOS roller coaster (since I will probably upgrade to CentOS 5 
once such a beast is in the pipeline, because the preview in FC5 of what is 
likely to be in RHEL 5 is compelling for upgrade, at least on desktops), at 
least that roller coaster is on a longer cycle.

Even Debian is now having this sort of problem, with Knoppix and Ubuntu in the 
mix, neither of which is a vanilla Debian.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu