[PD] enhance pd-extended with pd-l2ork featues ?

Ivica Ico Bukvic ico at vt.edu
Tue Jan 22 16:30:41 CET 2013


> 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" <hans at 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-
> >>
> >>
> >> http://qa.debian.org/developer.php?login=pkg-multimedia-
> maintainers at lists.alioth.debian.org
> >>
> >> .hc
> >>
> >




More information about the Pd-list mailing list