[Tom Lees <[EMAIL PROTECTED]>] > 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
