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