> 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: > > > > 1. the two are not binary compatible, so any stray packages may crash one > > or the other if they are in the shared directory > > > > 2. pd-l2ork comes as a monolithic distribution > > > > 3. 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" <[email protected]> > 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- > >> > >> > >> http://qa.debian.org/developer.php?login=pkg-multimedia- > [email protected] > >> > >> .hc > >> > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
