Feature idea: package an installer image as a grub entry before F8.

Colin Walters walters at redhat.com
Tue Jun 5 22:02:49 UTC 2007


On Tue, 2007-06-05 at 17:20 -0400, Jeremy Katz wrote:

> And even if there wasn't _anything_ in the python 2.4 -> 2.5 transition,
> that doesn't mean that there hasn't been in the past and won't be in the
> future.  Why would we want to tie the hands of a project like that? 

I was thinking the stack would just be one (Fedora) release back, not
forever stuck.  In other words you couldn't directly upgrade FC4->FC6.
If we made upgrades easy and reliable enough, there would likely be a
lot fewer people who cared about skipping versions.

But let's assume given your argument and the above that we would need to
take the full image approach.  It seems that the storyboard architecture
would look like:

o during development, fedora-upgrader-tool is built containing a base
  image with shell,glibc,python,yum, etc., similar to anaconda.
o fedora released
o pirut notices new major upgrade available
  - executes bittorrent to download fedora-upgrader-tool image
    or just http download depending on how big the thing is
o fedora-upgrader-tool is invoked by pirut
o fedora-upgrader-tool loopback mounts /var/lib/fedora-upgrade.img on
  /var/lib/fedora-upgrade-root, then:
  - copies the current package list into the root, and executes yum on
    it?  Don't know the lowlevel details here, but the idea is to
    download all the packages that are necessary for an upgrade
    * One possible optimization is to bittorrent a base image of
      the RPMS basically everyone has installed, then yum http 
      download the rest
o fedora-upgrader-tool notifies desktop session major upgrade is
  available, offers reboot
o grub.conf modified as appropriate, and things proceed as Will outlined





More information about the fedora-devel-list mailing list