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
