[CentOS] Why so many updates already for CentOS 5

John Summerfield debian at herakles.homelinux.org
Mon Apr 16 00:14:01 UTC 2007


Johnny Hughes wrote:
> On Sun, 2007-04-15 at 08:01 +0800, John Summerfield wrote:
>> Stephen John Smoogen wrote:
>>> On 4/13/07, John Summerfield <debian at herakles.homelinux.org> wrote:
>>>>> 1.  People want the versions of files on the CentOS to discs to match
>>>>> the upstream versions for software control
>>>> Some do, some don't. Some download at work and install at home. There's
>>>> 75 Mbytes of updates wouldn't get to my machines at home.
>>>> An updates repo in the collection would be a handy compromise, I think I
>>>> suggested this a while ago.
>>>>
>>> It sounds nice but has too many problems in implimintation:
>>>
>>> 1) Anaconda does not deal with updates during install. Upgrades need
>>> to be placed in the main trees and the disk would need to be respun
>>> regularly.  My memory is a bit weak here, but I think that trying to
>>> add the code to deal with 'updates' during install seems to have
>>> caused a lot of 'exceptions' in the Fedora code and causes anaconda to
>>> be even more memory happy.
>> Having them present is a great start.
>>> 2) Respinning the disks breaks upstream compatibility that a lot of
>>> ISV software looks for to see if a system is 'supported' and will run
>>> on it.
>> Specifically what? /updates in the root directory?
>>
>>> 3) If a person installs in 3 weeks from now when say another 75-200 MB
>>> of updates are available.. it doesnt help any (especially if those
>>> updates cover a lot of what was on the disk).
>> It's a good start.
>>
>>> 4) An updates iso might be possible, but it is more disk space on
>>> overtaxed servers and more work for the 3-10 core people.
>> use of jigdo can alleviate the first. A script run weekly by crontab 
>> would likely be enough.
>>
>>
> 
> OK ... maybe I am missing something here ... BUT
> 
> why can't the person in question just rsync down the updates dir for the
> arch in question and make an iso out of it ... then mount that ISO
> themselves?

Only if the mirror supports rsync. some do, some don't. jigdo uses wget 
and so uses whatever wget supports.

> 
> Then CentOS doesn't have to try to spin, save, distribute, etc. all
> these ISOs.
> 
> If I spin one extra CD (650MB) and distribute it to 200 mirrors (650MB x
> 200 = 130GB transferred) ... that ties up how much time and bandwidth
> for how many people and costs how many $.  
> 
> If 30% or more of our users were using it, it might be worth all that
> time and effort ... but it is also not hard to for any user to sync the
> right updates directory down (it already includes all the yum metatdata
> required) an burn it to ISO.

Other than rsync, what batch mirror tools are in CentOS 5? I used to use 
mirror, but then RH dropped it without, AFAIK, a replacement.


> 
> I don't see ANY major distro out there that makes this available,
> because it is largely untenable to scale this to a million user
> scenario.

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.

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.

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.

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.

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

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.

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.

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

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


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.




-- 

Cheers
John

-- spambait
1aaaaaaa at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu

Please do not reply off-list



More information about the CentOS mailing list