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-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
