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