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@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
Please do not reply off-list
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
