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