Proposal: Rolling Release

[Les Mikesell]

Rahul Sundaram wrote:
> 
>> 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.
> 
> Again, this is something upstream project should do. GTK and gstreamer 
> for example does make this easy.
> 
> http://www106.pair.com/rhp/parallel.html
> 
> Working around this at the packaging level is always going to require 
> elaborate hacks. OpenSUSE did this for shipping KDE 3 and KDE 4 in 
> parallel but other distributions refused.

I'm not sure I understand the logic of making upstream deal with the 
problem that RPM's design introduces.  There's rarely an issue if you 
want to do parallel version installs out of an upstream source - and I'd 
guess the developers _always_ do that for anything they rely on.

>> Think USB external, flash or laptop form.  They are great things to 
>> have around for other purposes too.
> 
> External USB's are not a answer in embedded systems. You cannot rely on 
> external disk storage for base os functionality.

OK, so there are tradeoffs.  If you are building embedded systems you 
probably need a spare one to test on. You really only need the backout 
capability until someone has thoroughly tested the replacement in the 
environment where it needs to run.  Or add a micro-sd slot so you can 
throw in an extra 16 gigs in an itty-bitty package when you need it - 
even my phone can do that...

As a minimal step you could add the capability of clonezilla to the 
install - that is, offer to save a compressed image backup somewhere 
before starting in a form that can be restored without a lot of work. 
That's not quite as nice as keeping old/new filesytems online so work in 
progress could be accessed/recovered from either version, but better 
than nothing.

-- 
   Les Mikesell
    lesmikesell at gmail.com