Re: Bug#66084: lvm: 0.8i -> 0.8final migration
[Tom Lees <tom@debian.org>]
> however, this does still leave a big problem: how to handle the
> upgrade from 0.8i to 0.8final. If you are currently using LVM 0.8i,
> then upgrade to 0.8final, LVM will stop working unless you also
> recompile your kernel.
Aye, there's the rub. It's a design problem that Heinz can perhaps be
forgiven since at the time LVM wasn't in anyone's standard kernels
(except perhaps SuSE). I do hope 0.8final is to be the last public
interface change....
> I thought I could maybe make an "lvm-0.8i_0.8i-..." package or
> something similar, which Replaces: lvm (< 0.8final), and is
> Recommended by the new lvm 0.8final.
Alternatively, borrowing a page from postgresql, have your preinst save
a copy of all the old binaries, in /lib/lvm-old or some such, and
arrange to invoke them automatically if the kernel is 0.8i. (It goes
without saying that /sbin/* should automatically run the right binary
somehow, whether via my wrapper script or whatever.) Then provide a
program /usr/sbin/lvm-configure, or whatever, that has an option to get
rid of the cruft when the user no longer has need of it.
The same preinst can detect a fresh installation and ignore the
compatibility junk.
> What exactly is the behaviour of apt when upgrading a package. How
> can I make it so that if you upgrade from the LVM 0.8i pkg to the
> 0.8final pkg, you get a compatibility package installed by apt or
> dselect or dpkg, but if you install the package fresh, that doesn't
> happen.
Not sure this can be accomplished at all. The big difficulty is that
`apt-get dist-upgrade' doesn't respect either Recommends or Suggests,
so to get its attention you need a full Depends.
> Or should I put some sort of warning in the preinst?
That would be by far the simplest thing to do -- warn the user that he
should install `lvm-compat' unless he really knows what he's doing....
> The ideal situation would be to have 0.8final the "standard" version
> for both 2.2 and 2.4 kernels, with a 0.8i compatibility package,
> IMHO.
Agreed.
Peter
Reply to: