procps-ng upstream have been busy getting the library into some initial
state plus a whole lot of other additions and fixes. I expect it will be
released soon which will solve the libprocps library issue.
The other thing to point out is the API of the library will change in
the next from this
On Wed, Dec 07, 2011 at 12:30:06PM +, Simon McVittie wrote:
Is libproc considered to be a public shared library or not?
And this, is really, the crux of the whole matter.
Is it? Was it supposed to be? Can it be?
Well, it seems that as there are at least 3 packages (maybe more) that
depend
On Fri, Dec 9, 2011 at 08:47:21 +1100, Craig Small wrote:
Given that, it needs to be fixed and made into a proper and
well-behaving library package, so I'm proposing that:
* libproc be split into its own package, probably libprocfs0
* the library file will have a proper SONAME that is
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,
On Wed, Dec 7, 2011 at 08:42:24 +1100, Craig Small wrote:
On Tue, Dec 06, 2011 at 06:47:09PM +0100, Jakub Wilk wrote:
Name of the shared library has been been changed (obviously, without
changing package name). This breaks at least xmem on amd64:
Then xmem should not be depending on
Package: procps
Version: 1:3.3.1-1
Severity: serious
Justification: Policy 8.1
Name of the shared library has been been changed (obviously, without
changing package name). This breaks at least xmem on amd64:
$ xmem
xmem: error while loading shared libraries: libproc-3.2.8.so: cannot open
On Tue, Dec 06, 2011 at 06:47:09PM +0100, Jakub Wilk wrote:
Name of the shared library has been been changed (obviously, without
changing package name). This breaks at least xmem on amd64:
Then xmem should not be depending on procps. Oh look, it doesn't even
have a versioned depends.
There was
7 matches
Mail list logo
