Ah yes, right, you have to build everything for pd-l2ork because of binary incompatibility. That's unfortunate, since it means you have to do all
the
same maintenance/packaging work instead of building upon what's there.
Well, it's not that much of work at all. The automated pd-l2ork build script already takes care of all that. True, there are still some externals that I did not include in the auto-build process but that should be a lot easier now that the core appears to be stable. Besides, my opinion is that shedding binary compatibility under these circumstances is really a non-issue when compared to benefits it yields, particularly considering that almost every new version of all three pd variants ships with newly recompiled externals and as such the process is entirely transparent to the user. Of course, if pd-extended adopted the pd-l2ork widgetbehavior, things could become a lot easier for all involved ;-)
Packages like pd-readanysf, pd-iemambi, and coming soon pd-fftease and pd-lyonpotpourri, are all built to be shared across different pd versions.
You
can still use the packages puredata-utils (pdsend and pdreceive) and
cyclist
with pd-l2ork.
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).
Unless pd-l2ork is looking in /usr/lib/puredata, then it will not use any
of
the objects included in the puredata* packages. The pd-* packages install into /usr/lib/pd, and Pd-extended installs into /usr/lib/pd-extended. If pd-l2ork does not install into /usr/lib/pd or /usr/lib/pd-extended, then
it
can coexist fine. Just make sure that /usr/lib/pd and
/usr/lib/pd-extended
are not in pd-l2ork's search path and it won't load those libraries.
Indeed, that is not the problem. The problem lies (potentially) in user-settings file that may mess things up even though pd-l2ork uses different file name.
Best wishes,
Ico
.hc
On 01/22/2013 08:57 AM, Ivica Bukvic wrote:
Because:
- the two are not binary compatible, so any stray packages may crash
one
or the other if they are in the shared directory
pd-l2ork comes as a monolithic distribution
Pd-utils is enough to break the one or the other due to different
ways
how gui functions between the two.
If you can think of a better way please do let me know.
That said, the two can nicely coexist if you install one of them using
the
binary installer script because that one exists in the usr/usr/local directory as opposed to/usr. Pd-l2ork already provides binary installers and automated tarball builders.
P.S. I tried building pd-extended but had no luck using the same "make install path=/usr/local" (as per readme in packages/linux). I will try
to
resync latest svn. Perhaps something has changed. On Jan 21, 2013 11:58 PM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
On 01/21/2013 11:22 PM, Ivica Ico Bukvic wrote:
Interesting, I'll have a go at it.
I think I said I'd pay you if you were able to fix this. Or maybe
that
was
matju. Either way if it's fixed I'll pay you for it.
To be honest, I have no earthly idea why I care so much about this feature. Perhaps it's from going through the hamster-wheel of externals all written
just
to
get
the args list when this is all that is needed to solve all but the exotic
cases.
-Jonathan
You can also try the binary builds I just posted (20130121 version)
that
has
all of the aforesaid fixes (assuming you use Ubuntu).
Cheers!
Hey ico,
I'm curious why you made the pd-l2ork package conflict with all of the puredata packages. As far as I can tell, it only conflicts with puredata-utils. It would be very handy if pd-l2ork could live in
parallel
with pd and pd-extended.
And in terms of lowering your maintenance load, you could remove lots
of
libraries from pd-l2ork and instead set them in Depend: and have them provided by the official packages that are already in Debian and Ubuntu. You
can
see a listing of what's included in Debian here: look for all the packages
that
start with pd-
maintainers@lists.alioth.debian.org
.hc