Hello, I am working on packaging roccat-tools (bug 718032) and I have come across a situation that I am not sure how best to handle.
roccat-tools is structured as a daemon with one plugin DSO per Roccat mouse model. The plugin DSOs are installed to a private directory and the daemon loads all the installed plugins from that directory at start-up. To configure the daemon and hardware, each Roccat mouse model also has its own command-line utility and graphical settings editor. Since most users will own only a small subset of Roccat's products, it makes sense to distribute all these model-specific files in model-specific packages--e.g. roccat-driver-konepure for the Kone Pure mouse model. (This avoids installing a bunch of .desktop files that the user has no interest in.) These model-specific files all link to private DSOs for common code specific to that model (e.g., libkonepure/libkonepurewidget) and common code shared by all models (libroccat/libroccatwidget). Upstream installs these to the same directory as its plugins and adds that directory to the ld.so search path, but there's not much point in that as pointed out by the package-modifies-ld.so-search-path Lintian tag. Additionally, a few mouse models make use of the private DSO for a *different* (but related) mouse model. e.g., the model-specific files for the Kone Pure Optical link to a private DSO for the Kone Pure. My conundrum is this: given that we want to package the model-specific files in a roccat-driver-<model> package, how should we package everything else? I have come up with a few alternatives: 1) Treat all the private DSOs as if they are public DSOs and install them in the public shared library directory in their own lib* packages, but without any corresponding -dev package. This has the disadvantage that their short library names will be at risk of colliding with other libraries. e.g., one of Roccat's mice is called "Lua" and the private DSO for it is liblua.so, which users are likely to confuse with the Lua language interpreter's libluaX.Y.so. 2) Like (1), but install to a private directory and have everything in roccat-tools declare an rpath to it, thus avoiding ld.so collisions. This triggers binary-or-shlib-defines-rpath, but IIUC this would be an accepted use. However, the private DSO package names would still confuse people. 3) Like (1), but patch the source to use more verbose DSO names, e.g. libroccatdevicelua. No confusion or risk of collisions anymore, but the private DSOs still polute the public shared library directory. 4) Like (2), but deviate from the standard lib package naming convention to be more verbose--e.g., put liblua.so.2 in roccat-modules-lua2. No confusion or risk of collisions, but relies on rpath. Are any of these more Debianesque than the others? I am currently leaning toward (4).
