On Wed, 07 Dec 2011 at 08:42:24 +1100, Craig Small wrote: > There was a reason why we said not to link to libproc, this one of the > reasons.
Is libproc considered to be a public shared library or not? If it is, it should probably be in its own package with the usual SONAME-tracking, parallel-installability sorts of things; or failing that, provide a SONAME-named virtual package that things linking to it can depend on, and have suitable dpkg-shlibdeps magic to make that happen, so that xmem etc. can't be co-installed with an incompatible procps. (Perhaps depending packages would "Depends: procps (>= VERSION), libproc-ng-x.y.z" or something, where the latter is virtual.) If it isn't a public shared library, then it should go in /lib/procps (or even /lib/TRIPLET/procps) with an RPATH, and things that currently link to the shared library should link to it statically (and have Built-Using), or even have their own copy. Whether it's considered to be a public shared library also affects the correct solutions to #651179, #650314 and #646834, I think? S -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org