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.