On Fri, 2007-04-13 at 12:03 +0100, Karanbir Singh wrote:

Mário Gamito wrote:

...

Hi,

I've just installed CentOS 5. I issued a yum update, and to my astonishment there are already 75 MB of updates. And i didn't even installed X.

Why is this ?

These are packages that have been updated since the time CentOS-5's package tree was frozen upstream. Btw, you might want to check what the updates are - its possible you have more software installed on the machine than you need.

• KB

To explain this a little more ... here goes:

1. People want the versions of files on the CentOS to discs to match the upstream versions for software control .. so if you install 5.0 it is as close a possible to 5.0 upstream.

2. Upstream released a Cubic buttload of updates since the 5.0 release. These where included as updates for CentOS-5 as well ... see these links for all updates released:

http://rhn.redhat.com/errata/rhel-server-errata.html

http://rhn.redhat.com/errata/rhel-client-workstation-errata.html

All we did was include them as updates ... so CentOS-5 is now all updated, to 4/12/2007.

Thanks, Johnny Hughes

chrism@imntv.com spake the following on 4/13/2007 12:18 PM:

Johnny Hughes wrote:

...

2. Upstream released a Cubic buttload of updates...

Is that one of those fancy new metric units that we're not using here in the US of A yet? :)

( i ) ^3 ????

Cheers,

A cubic buttload is just a buttload squared times a buttload deep. ;-P

Johnny Hughes wrote:

On Fri, 2007-04-13 at 12:03 +0100, Karanbir Singh wrote:

...

Mário Gamito wrote:

...

Hi,

I've just installed CentOS 5. I issued a yum update, and to my astonishment there are already 75 MB of updates. And i didn't even installed X.

Why is this ?

These are packages that have been updated since the time CentOS-5's package tree was frozen upstream. Btw, you might want to check what the updates are - its possible you have more software installed on the machine than you need.

• KB

To explain this a little more ... here goes:

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.

Stephen John Smoogen wrote:

On 4/13/07, John Summerfield debian@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.

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@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.

On 4/16/07, Ralph Angenendt ra+centos@br-online.de wrote:

John Summerfield wrote:

...

Other than rsync, what batch mirror tools are in CentOS 5?

lftp - works with ftp and http and does http better than wget does.

Ralph

I second this. I had difficulties with wget. Just couldn't get it to mirror correctly. Have been using lftp to maintain my local repo's. This one-liner mirrors the i386 tree, for example.

lftp -e 'open http://mirrors.kernel.org/centos/4/updates && mirror -c --delete i386 && exit'

Akemi

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.