Shrinking/splitting up core Was: Why are there only i686 and i586 Version of glibc...

David Kewley kewley at cns.caltech.edu
Mon Jun 7 18:50:53 UTC 2004


On Monday 07 June 2004 11:05, Steven Pritchard wrote:
> That employer is using a *ton* of RHL now, and upgrades are nearly
> unmanageable.  Paying for RHEL would reduce the frequency of necessary
> upgrades, and the money isn't necessarily a problem for them, but how
> would they do all those upgrades?  (In other words, I don't think this
> is just a problem for Fedora Core/Extras/etc. users.)

FWIW (and I know this is mostly OT), I don't think any large installation 
should be doing upgrades of individual machines -- only installs.  If they 
*need* to do that because they can't replicate the original installation 
*automatically*, I think that's poor system management.  What are they going 
to do when a hard disk fails?  Try to remember all the manual changes made to 
the machine?

What we do is have a kickstart/cfengine system that can reinstall any given 
node at any time.  Upgrade?  No problem.  First upgrade the ks/cf system to 
support the new release, then reinstall machines using it.  I think it's 
becoming more and more standard these days to do something like this.

I look at the anaconda upgrade functionality as something for legacy 
environements, unknowledgeable users, or simple convenience.  But then, I 
don't think I've ever done an upgrade in *any* OS -- only re-installs. :)

But I expect that if Fedora decided not to support anaconda upgrades, there'd 
be loud screaming from users and slashdot pundits.  So my comment is mostly 
just about what large installations should be doing, regardless of whether 
they're using Fedora or some other OS/distribution.

David





More information about the fedora-devel-list mailing list