On Mon, 2006-03-13 at 11:10 -0500, Lamar Owen wrote:
> 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.
Right ... not blessed because they change some major things like the
samba version, etc. This is not necessarily a bad thing, but the end
result is not CentOS. I have a test machine running KDE-RedHat ... it
is more stable than FC (for example).
>
> 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.
This is absolutely true ... if you want that functionality, you have to
use those pacakges. Axel does a great job ... I am using his mythTV on
a CentOS machine. BUT, I don't expect that machine to rock solid stable
like the other centos machines I have. It isn't good or bad ... it just
is, if you want MythTV on an machine, it requires some cutting edge
packages, that is just the way it is.
> 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.
This is also absolutely true ... Enterprise Linux is designed for
stability, it is not designed for "Latest and Greatest". In fact,
Fedora is a very good Latest and Greatest distro, if that is what you
are trying to accomplish.
You will notice that the Unbuntu guys now want a 6 week delay to roll
out their latest version as they get stuff just right to support it for
more than a year (they are trying to make the new version be
Enterprise).
>
> 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.
Good wisdom in the above paragraph :)
>
> 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.
That is also a good point ... a CentOS with updates might prove to be
more long lived and more stable than a FC distro, and people might want
to do that ... but they should not expect CentOS to support it :)
>
> Even Debian is now having this sort of problem, with Knoppix and Ubuntu in the
> mix, neither of which is a vanilla Debian.
I just want to point out that I agree with almost everything that Lamar
said here.
I also want people to understand that CentOS 5 will be released in the
not to distant future .. and we are not trying to make CentOS 4 BE
CentOS 5 before it is released. We do add some things to CentOS 4 for
longevity (like mysql5 and php5 and XFCE, etc.).
BUT ... CentOS is not interested in duplicating things in KBS-CentOS-
Extras, dag, dries, ATRPMS, KDE-Redhat, etc.
A question was asked about APT ... and why CentOS released it even
though it is released other places. In this instance, apt was released
by CentOS so that the apt sources file could be created and that you
didn't have 3rd party repos enabled by default. It was provided as an
extra for doing CentOS updates by people who wanted to do that. Since
we did not want to enable 3rd party repos by default, a new version of
apt for centos was required.
This happened BEFORE fedora extras included apt and before fedora extras
was built by Karanbir.
Thanks,
Johnny Hughes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20060313/e812362b/attachment.bin
