pd-extended should use puredata-utils, but it doesn't yet. It will in the next release. Nothing requires puredata-utils, its optional.
.hc
On 01/22/2013 11:16 AM, Ivica Bukvic wrote:
AFAIK I use pd-l2ork exclusively, not pd. I f you find it anywhere that I'm not using that please let me know so I can fix it.
I need to check whether pdsend/receive is indeed identical before making any calls on that matter. Even then if one has to uninstall pd-utils due to conflict with pd-L2ork what would that mean to the rest of the install as far as pd-extended is concerned? Would it still work, or is pd-utils a dependency (as far as I can tell it should be a dependency because otherwise pd wouldn't work without it)? On Jan 22, 2013 10:46 AM, "IOhannes m zmoelnig" zmoelnig@iem.at wrote:
On 2013-01-22 16:30, Ivica Ico Bukvic wrote:
Pd-l2ork indeed has its own folder (including pd-l2ork-externals in home folder and settings file). The conflict is in the /usr/bin/ folder with binaries that share the same name but not necessarily code-base (I think pdsend/pdreceive and something else, IIRC--cannot remember off top my head).
since i trust that you haven't done anything to pdsend/pdreceive, i guess it is save to simple use the debian-package "puredata-utils" instead of providing your own. alternatively, you can make your package conflict with "puredata-utils", in order to avoid the conflict.
the other thing that comes to my mind is obviously "pd" itself. i guess you are using "pd-l2ork" as binary name, so this wouldn't be a problem. (but if indeed you do use "pd" as the binary name, i suggest to switch to "pd-l2ork" instead and eventually provide an alternative diversion from pd to pd-l2ork, using the "update-alternatives" mechanism)
fgamsdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list