Proposal: Rolling Release
Les Mikesell
lesmikesell at gmail.com
Mon Nov 10 21:01:19 UTC 2008
Rahul Sundaram wrote:
>
>> So the RPM design forces you to not use it at all. Great.
>
> Deb or other package management systems are no different here. They are
> all designed to be non-interactive. Debian used to dump questions on a
> terminal for some packages but that is not recommended anymore for
> obvious reasons and everybody is advised to used to use debconf. There
> is only limited magic you can do to workaround incompatibilities of
> certain kinds. Postgres frequently requires a dump and restore.
And you may need both old and new versions present while you perform the
operations an upgrade requires. So generic package-magic would involve
being able to install the new version without removing the old so you
have a chance to do the interactive parts before it is too late. That
would be a nice feature to have in general but pretty far from existing
practice.
> But, that
>> brings back the concept of migration. Is there any interest in that,
>> so your upgrade becomes a non-destructive copy that you can test
>> before the old copy is gone? Disk space is cheap these days.
>
> You have to explain how that will work for a complex dependency set.
> What about say glibc breakage? You are going to need filesystem
> snapshots I suspect.
I'd like it to not touch the existing system at all. One approach
would be to migrate to a different machine, which I consider a badly
needed feature on its own. Macs have done this for years, using
firewire target mode on the old system to access it as a disk drive and
providing automated copy plus update of the existing users,
applications, and data. Any technique that permits a backup/restore of
the old system followed by an upgrade that would also do the fixup for
potentially different hardware would work, though. Building a
virtualbox/vmware (etc.) clone should be a transparent variation of
this, but you need the 'migrate to hardware' tool that doesn't exist.
Another would be to have pre-allocated a spare partition - or add a new
one, perhaps via USB where you copy the old system, then upgrade, making
a dual-boot setup so you can go back to an untouched existing system if
necessary. In the USB case, you would need a subsequent migration step
to move the partition over the old system after you were convinced it
was safe. I've done alternate-partition installs manually in the past
but it takes some tweaking, and if you maintain the existing /home,
there is no way to know which files you need to save/restore between
versions so that should be automated too.
> Btw, disk space is not always cheap. Think: thin clients, embedded
> systems, netbooks like OLPC or eeepc etc.
Think USB external, flash or laptop form. They are great things to have
around for other purposes too.
--
Les Mikesell
lesmikesell at gmail.com
More information about the fedora-devel-list
mailing list