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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
