> On Sat, 2005-05-28 at 00:54 -0500, Les Mikesell wrote:
> > On Fri, 2005-05-27 at 19:13, Lamar Owen wrote:
> > > On Thursday 26 May 2005 14:17, Les Mikesell wrote:
> > > Is there a reason that a Centos or third-party repository
> > > could not be arranged such that an explicit upgrade could be
> > > requested to a current version which would then be tracked like
> > > your kernel-xxx-version is when you select smp/hugemem/unsupported?
> >
> > Yes, a couple: 1.) Lack of manpower to do the tracking; 2.) Doesn't fit the
> > purpose for which CentOS was targeted. CentOS is supposed to be 'I Can't
> > Believe it's not Red Hat' enterprise Linux. That 'explicit upgrade' might
> > break many many things.
>
> Whatever happened to the Caos distribuion? I had some hopes that they
> would combine a very stable kernel/libc combo with very up-to-date apps.
>
The cAos foundation is alive and well at http://www.caosity.org/ ...
although the CentOS Project is not part of the cAos foundation any
longer. They just released cAos-2.
They do have a fairly long release cycle and they do incorporate newer
packages into the mix. In fact .. they might be a closer fit to what
you are looking for. Although, they have a newer kernel than CentOS at
2.6.11.6
> > For instance, suppose you want PostgreSQL 8 instead of the supplied 7.4. Ok,
> > now you have a maintenance nightmare, as all kinds of packages link to libpq,
> > and the current 8.0.x release has a bumped libpq soversion. So how do you
> > deal with this without making it virtually impossible for the maintainers to
> > maintain? (I know the answer to that, but it creates its own problems, and
> > that is a compat-postgresql-libs RPM to supply the older libpq, but that
> > doesn't tackle all the problems).
>
> So how is it better that when you do get Postgresql 8 in a distribution
> you will likely get a largely untested kernel along with it? Or that
> you compile your own version and end up with potentially unique problems
> that every user has to solve individually?
For certain items (php5, postfix with mysql suport compiled in, a kernel
with some new different features turn on) we have created a CentOS Plus
repo for CentOS-4 ... but the number of things we can do there is
limited by a several things:
(1) Resources - It takes 50gb now, and at the final state probably
closer to 100gb, to mirror CentOS. We are averaging 16.50 TB
transferred monthly just to do the distro, updates and supply the public
mirrors. We have to somewhat limit what we add to the mirrors so that
we can mirror it effectively. We only have so many servers and so much
bandwidth ... and CentOS Base has priority.
(2) Time - Someone has to regression test and maintain the added
programs on CentOS-4 ... and those items DO NOT get nearly the
stability / regression tests that RH puts in the RHEL-4 base. We only
have so many developers (none of whom get paid a dime for doing anything
for CentOS) ... and again, CentOS Base has priority.
(3) Number of Changes - If something requires other major items to have
to be upgraded (i.e., a new version of glibc, libstdc++, python, etc.)
then we will not add it, even to CentOS Plus. The end result, even with
items installed from CentOS Plus, still needs to be CentOS-4.
> > Which combinations should be supported?
> >
> > Now exponentiate by a factor of 1000 packages.
>
exactly ... CentOS certainly can't support that.
> I used to laugh at the people running windows servers because they would
> not even try to run more than one application per machine. But that was
> when I compiled a lot of stuff by hand. Now that I've gotten lazy (or
> smart...) and try to stick to binary distributions, I don't laugh any
> more because now my Linux boxes are in exactly the same shape. I can't
> count on being able to upgrade any single application without breaking
> another one.
>
> > Not reasonable to do given the resources. Why not just use Fedora, since it
> > tracks more or less what you want? Or, use gentoo. Or get really ambitious
> > and do Linux From Scratch and make it just exactly how you want it.
>
> Fedora breaks everything at once, so it isn't what I want. I want
> "something like" being able to install a Centos 3.x base, then
> selectively update certain apps to current-fedora level. A lot of this
> would work with just a source rpm rebuild - but what I'm really after
> is something that once done would still automatically pull updates
> when the selected packages were fixed.
>
Gentoo might just be the exact choice you are looking for ... you can
have whichever kernel you want ... and only upgrade the packages that
you want. They have a huge number of supported packages ... and they
move forward fairly quickly. You can have some packages at the ~x86
level (newer, testing level) and others at the x86 level (normal
stable) ... you can eve specify some packages to hold back to specific
levels behind the current stable.
If you setup you portage and package configurations correctly ... when
you upgrade an individual package, all dependencies are figured out and
installed.
> > > There are times when you want predictable behavior, and times when
> > > you want correct behavior. When an upstream app makes changes
> > > that provide correct behavior but you are ensured of the old
> > > buggy behavior as a matter of policy, something is wrong.
> >
> > What is 'correct' behavior? Doesn't correctness depend upon the customer? Is
> > it possible that CentOS (and RHEL by extension) is Not For Everybody, but
> > targeted to a particular set of customers?
>
> I think character set conversion is something where the correctness can
> be determined objectively. And perl on Cento3 and Centos4 will do 2
> different things. I'll take the perl team's word for it being made
> correct in 5.8.3 and up.
>
But the perl team didn't verify that those changes will work with the
rest of the packages that are in RHEL-3 or RHEL-4 ... and don't break
anything. I do not want to upgrade and have other things not work. The
bottom line is, RHEL does not normally change major packages to new
versions in a release cycle ... if it ships with Gnome 2.2 and
OpenOffice.org 1.1.2 ... that is going to be the gnome and OOo
throughout the lifetime of that product ... they are not going to
upgrade that to gnome 2.10 (or even gnome 2.4) or OOo 2 ... ever.
When people get RHEL (and CentOS) in the enterprise, they add things
like Oracle and build/install customized CRM / ERP programs costing
millions of dollars into it ... they can't have something change that
breaks that once they get it working. They want a stable OS that gets
security updates for those machines ... not a new program that makes
them have to recompile all the code they based their business on.
> > If you want your custom versions of apps, then you can either do the legwork
> > yourself (that is, backport your own security fixes) or pay someone to do it.
> > If no one else wants it, then you will pay lots of money. But a volunteer
> > project is under no obligation to fill the needs of every person who wants it
> > 'their way' unless said person can afford to either do some legwork or pay
> > someone to do some legwork or convince the Powers That Be that It Is Such A
> > Good Idea that the project cannot do without it.
>
> I have a feeling that the 2.6 kernel will become usable before that
> happens this time around, but maybe by the next time RH rushes out
> a largely broken release there will be viable competition in Ubuntu
> and other distributions that will keep a working kernel under a
> fast release schedule for the apps.
>
Let's be clear here ... Red Hat could care less about Ubuntu, Gentoo,
Slackware, Debian, Mandriva, etc. They added 2.6 kernel support for one
reason ... because it was in SLES 9 and they were taking a beating in
the Enterprise Market. (And it was time for a new release ... 18 months
from RHEL-3).
They didn't rush they were the last to put in a 2.6 kernel :) ... but it
does have some issues. It works fine for me, and for the majority of
the people who use it. There are known kernel issues that will be fixed
in U1.
-------------- 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/20050528/18835a47/attachment.bin
