Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades?

Nicolas Mailhot nicolas.mailhot at laposte.net
Wed Nov 30 21:47:25 UTC 2005


Le mercredi 30 novembre 2005 à 16:21 -0500, Bill Nottingham a écrit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > Anaconda requires you to get an installation image somewhere and burn it
> > to a CD/DVD. A firstboot package would just add an entry to the usual
> > boot menu, and work even on a CD-less system. Plus a firstboot could be
> > split into "manage partitions" "manage lvms" ... tools, while anaconda
> > only knows about update process.
> 
> On install, anaconda could copy it's own boot image and stage 2 to /boot,
> and allow you to boot that later without a CD. 
> 
> Bill, not very serious, but....

You know, at one point anaconda was the only tool which knew how to do a
full system package upgrade. Then dedicated tools appeared, where
generally useful outside anaconda, and as a result anaconda is rewritten
to use yum as a better package upgrade engine.

I claim :
1. most of the remaining anaconda features can be moved to either
general-purpose tools (like yum) or a release-specific function bundle
(hopefully as small as possible)
2. the parts that require a cold system can be accessed easily from a
bootloader entry which removes the need of burning a CD for upgrades, or
even having a separate boot media than the upgraded system altogether

For new installations the same tools would be linked in a CD wizard
install process like today. But for everything else (upgrade or general
system maintenance) there would be no reason to go through the anaconda
bits useful only for fresh installations.

You'll note windows mastered this a long time ago (windows is the reboot
genius). As long as something can be done on a live system FC is quite
superior. But for all the rest windows will just create a new management
boot mode (and ask the user to reboot), while FC will ask the user to
boot on the install CD, and somehow manage manually to run the required
utilities while avoiding to actually follow the install process to its
end.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051130/a0e605f4/attachment.sig>


More information about the fedora-devel-list mailing list