Proposal: Rolling Release

[Les Mikesell]

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