On Monday 31 December 2001 19:23, Matt Zimmerman wrote: > I have a set of packages which work for me, but a few things will need to > be resolved before they can go into Debian proper. > > - Shared library versioning > > libevms and libdlist have sonames with no version number (libevms.so and > libdlist.so). I assume that this is because the APIs aren't yet stable > and you aren't worrying about binary compatibility yet, but this setup > will cause problems for upgrades, and as such does not meet Debian > requirements. There are at least couple other ways to approach the > situation: > > - Use a soname like libevms-0.2.4.so, where there is implicitly no binary > compatibility between versons, and multiple versions of the library can > be installed at once. This is my preferred method. > > - Only provide static libraries until normal soname versioning makes > sense > > What are your feelings on this?
I thought libevms did have a version number. There ought to be a libevms-0.2.4.so, with libevms.so as a link to the specific version. Is that not how it's set up on your system? Currently the dlist package doesn't have any version number, but I'm sure we can come up with one if it makes things easier. I will try to do that tomorrow. > - Manual pages > > Debian requires that every program have a manual page. This is not a big > deal; I will write the man pages if you don't have any. I believe we have someone working on some man pages. Currently I think they will just be for evms (command line) and evmsgui. I will check to see if we can write some man pages for the LVM-emulation utilities. If you'd like to take an initial shot at those, feel free. > - Makefile stuff > > I modified the makefiles to support DESTDIR, and to remove the autoconf > clutter in 'clean' instead of 'distclean'. I can't run 'distclean' from > the package build scripts because it removes 'configure'; I'm not sure > why this is, since configure is part of the distribution. My diff is > attached. I guess I've never used the DESTDIR construct before. I assume that is just an externally set environment variable? I will patch in these changes to the Makefiles. Because new plugins are still being written for the engine, we set up the Makefile to remove 'configure' on a 'make distclean'. This forces you to run 'autoconf' to regenerate 'configure' in the event new plugin or user-interface subdirectories were added to the engine. I suppose in the future, before releasing a package I should modify the Makefile to not delete 'configure' on 'make distclean', since the end-user will have no need for this functionality. > > > I have not as yet built a kernel with the EVMS patch. I hope it is > > > possible to include both LVM and EVMS for migration purposes; is this > > > true? > > > > Yep. I run kernels with both EVMS and LVM enabled. Just make sure you > > don't mount the same LV with both systems at the same time. Also, if you > > make any volume modifications with one system (add/delete LVs, add/delete > > PVs from a VG, etc), you may need to reboot in order for the other to > > pick up the changes. > > I have a device which used to be LVM PV, but is no longer in any VG, and I > want to give the device to EVMS to use as a new segment to play with. It > was still claimed by the LVM region manager, though (in > LVM_Unassigned_Group). The only way I could release it was to zero out the > first sector and run evms_vgscan. Was there a better way? There is an LVM-emulation utility called 'evms_pvremove' that should be used on unassigned PVs to remove them from the LVM region manager. It is basically the opposite of 'evms_pvcreate'. We are working on similar functionality for the GUI. -Kevin
