On 2018-04-25 13:08, Roman Haefeli wrote:
On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
On 2018-04-25 10:59, Roman Haefeli wrote:
Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie. Now, that I had to compile purest_json myself,
btw, what is wrong with the pd-purest-json Debian package?
Nothing. It seems to use the certificate store from the system already. It works well for me. Thanks for pointing me to it.
afaik, the version in buster
I am on Debian stable (Stretch). The version of Buster doesn't matter for me.
i might provide backports of (select) pd-packages. just like i already provide a "puredata" (0.48) backport to stretch users.
Regarding my other mail: I'm not looking for a solution, as I don't have a problem using the package from apt or compile my own. But I'm curious to know whether it is possible as a Deken package maintainer to address the problem of different versions of linked libraries.
short answer: no. longer answer: sure. people only need to include all the dependencies locally (in this case, the deken package would need to provide a "libjson-c2.so" file and the externals, e.g. "rest.pd_linux" would need to look for this dynamic library locally (in addition to the system paths)). repeat this for all other (non-standard) dynamic libraries your external depends on. repeat this for all (non-standard) dynamic libraries required by all (non-standard) dynamic libraries your external depends on. recurse until there are no more non-standard dependencies left.
just to give a quick impression on the numbers of dynamic libraries:
$ ldd zexy/zexy.pd_linux | grep -c .
4
$ ldd purest_json/rest.pd_linux | grep -c .
32
if you are only interested in libraries in '/usr/' (as a crude measurement on "non-standard" library):
$ ldd zexy/zexy.pd_linux | grep -c /usr/
0
$ ldd purest_json/rest.pd_linux | grep -c .
21
fgasdmr IOhannes