[CentOS] Why so many updates already for CentOS 5

[Jim Perrin]

> Major vendors aren't playing catchup, when they create their masters
> that are no updates available. Their images include all available fixes.
>
> We are playing catchup, it's the same game Amdahl and Fujitsu and others
> used to play in the mainframe game, that IBM played with Windows
> compatibility on OS/2, that AMD does now.

We're not really playing catch-up either. We're pushing against the
clock, and software quirks to get a stable product out the door within
a timeframe the userbase is comfortable with. If our install isos are
updated or differ from upstream, then driver disks stop working for
installs, cats and dogs start living together. It'll be mass hysteria
I tell you.

> When a vendor releases, there's always a big batch of updates released
> too, from "product is frozen" to "here's the product." It's almost
> certainly the busiest time of all in the product's life.

Amen.

> We _can_ use the catchup process to our advantage. Red Hat's found a
> cubic buttload of problems with our software, and if we can distribute
> them then I think we should.

We do. The same as we always have, via yum in the updates directory.

> The question is not whether, but how. If your experience is that some
> CentOS users want to be able to install the same buggy software that RH
> shipped but has now fixed, then maybe our solution should allow that.
>
> I don't propose that we should continue shipping new respins of the
> whole product every week or whatever, just that in the first instance we
> should, as the major vendors do,  ship with all known problems fixed.

Most vendors don't ship with all known problems fixed. They ship with
an amount of bugs they're comfortable with, in a product they feel is
stable enough to release to the public.

Rolling in updates was discussed on the devel mailing list previous to
the beta and in several discussions on irc. Each time it was voted
down, because it changes from the 100% upstream compatibility mindset.

> If we can agree that all the updates should be included, then we can
> address the question of how they get applied.

They should not be included, but they should be easily obtainable.
Really, I don't see how this is different from any other OS. RHEL5
users install, then immediately do an update. Windows users install,
and then immediately do an update. It's pretty much par for the course
with a new OS install. The only difference here is that we knew about
the updates prior to release.

> If Anaconda supports it (I think this the major reason for using yum,
> but it might not all  be there yet), an option to choose to use the
> updates at install time's probably best.

Anaconda does support this, but there are bugs making it a non-solution

> Possibly, an interactive kickstart would do the job, with  %post section
> that asks what to do with the updates. This would not require changes to
> anaconda, but might surprise those who write their own kickstarts and
> don't read documents.

Suprising users who write their own kickstarts is bad. I'm not going
to mess with someone who does 30-40+ at a time, as he's probably
already figured out exactly how he wants his updates.

> For sure, a centos-firstboot would be able to do the job.

Possibly.

> So would seeding and configuring a local repo, so that when the user
> runs 'yum update' they're found, not downloaded.

You'll run into disk space issues here. and how do you pick where,
which may be different on every system.

> How should they be distributed?
> In the DVD image, they could be in a separate directory one that does
> not exist in RHEL. Maybe /updates.
>
> In the CD set, maybe a separate CD image.
Still better to have the user make the call with a utility like lftp's
mirror function or dag's mrepo.

-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell