On Mon, Dec 14, 2009 at 05:03:01PM -0300, Felipe Sateler wrote: > You mean installing it as /usr/lib/liblua5.1-luaCsnd.so and symlinking > it to /usr/lib/lua/...? The problem I have is that the lua module does > not have a SONAME, since it is not really meant to be linked by C > programs. C/C++ programs can use the proper libcsound64.so and > libcsnd.so (which this module is wrapping). Is there any real benefit > for this change?
I see few advantages 1) you may want to write a C++ application that embeds Lua and wants to provide a standard set of Lua modules. In that case you really want your application to be linked against the .so, so that dh_shlibdeps adds proper dependencies for you, and the linker complains if the required .so is not there. Moreover, lua provides an appropriate table for preloading modules that are linked (dinamically/statically) with the main application. This application may or may not be direcly linked with libcsound64. Libraries used by regular applications should be in /usr/lib, so that no extra -L flag is needed (and yes, I usually provide a .pc file to ease compilation). 2) you may want to provide also .a files (usually discouraged for system wide applications, but a nice addition for people using Debian to compile an all-in-one boundle for their softwares. The .a does not really fit the /usr/lib/lua/5.1/ path. 3) the lua module does not have a soname, it essentially exports a single C function, so ABI is unlikely to change. What may change is the API exported, that would reflect changes in the cnsd APIs. I thus suggest to use the same .so.X.Y.Z you use for csnd. 4) the naming schema for .so and the module name are unrelated. I prefer having all Lua libraries with a coherent name, liblua5.1-FOO.X.Y.Z and be free to use a different name for the lua module, like csnd. Note that also allows you to do aliasing (2 names for the same modules) to eventually ease a transition; that is, an indirection layer with all its benefits Cheers -- Enrico Tassi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
