On Sun, 14 Dec 2008, Robert Scheck wrote:
Hello Till,
On Thu, 11 Dec 2008, Till Maas wrote:
I agree here. I already mentioned some methods in another e-mail. Another
possibility I just thought of would be to create reverse delta rpms, i.e.
before an rpm is installed, a delta to the current state is created and stored
somewhere. This can then used to restore the previous state. Of course someone
needs to write this. :-)
Shrug. Who will be the lucky guy doing this? IMHO delta rpms are making the
handling of packages just more complicated, even they e.g. save traffic.
Oh, did already implement somebody the downgrading once the last update
using a delta rpm was broken? That's a thing, e.g. openSUSE is AFAIK now
lacking for years and nobody took care there, even they're using delta rpms
also for years now there. In fact, I wasn't seeing a working downgrade at a
bigger Linux distribution until now once delta rpms have been in use there.
the downgrade problems are as follows:
1. scriptlets are not reversible
2. downgrading works provided the user data/user config is not modified by
an update in a one-way process. (ex: mysql upgrade from 4->5 will convert
a db, but going back the other way won't fly)
3. There are certain processes which no one is ever going to do the work
to make them reversible: lvm1->lvm2, db transitions, udev migration,
ext3->ext4.
The problem is not putting the pkg bits back on the disk. The problem is
all the stuff that goes along with making the bits WORK.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
