On Jun 10, 2010, at 1:05 PM, IOhannes m zmölnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

...

On Wed, 2010-06-09 at 22:09 -0400, Hans-Christoph Steiner wrote:

...

Until we get the 'puredata' package installing its extra stuff in a separate dir from /usr/lib/pd, then its tricky to make 'pdextended' use /usr/lib/pd. But once that's separated, its easy.

hmm, i'm not sure i fully understand the need.

• • external-packages (e.g. pd-wiimote), have to install somewhere,

the obvious place would be /usr/lib/pd/extra (for both puredata and pdx)

• • "puredata" provides almost no externals (and they could be

factored out into separate packages): expr~, fiddle~/sigmund~, pd~,... (~10)

so what's the bug advantage, if "puredata" installs into /usr/lib/puredata and also searches /usr/lib/pd/extra (since /usr/lib/puredata/extra is virtually empty)?

with pdx it is (currently) a bit different as it comes with so many externals, and we want to avoid conflicts with pd-externals (and simil.)

installing to .../puredata has the theoretical advantage of allowing to install externals that are known to not work with PdX, and thus won't interfere, if PdX was looking in /usr/lib/pd/.

i think this is rather theoretical (currently i don't know of any such external), but at least it allows for this possibility.

thus it's probably more "elegant" and "cleaner". is it worth the effort?

mfgas.r IOhannes

PS: sorry if i started a new thread for an already existing one; it's actually a reply to a private email from roman, turned into pd-dev

Since we discussed this in IRC, I think its appropriate to include that:

IOhannes:do you think there is any real advantage if "puredata" would install into /usr/lib/puredata [1:09pm]•IOhannes has just written an email to pd-dev following up the discussion here [1:10pm]_hc:yes, very much so [1:11pm]_hc:my opinion hasn't changed since the last time this was discussed on pd-dev [1:11pm]IOhannes:sure [1:11pm]IOhannes:but what is the advantage? [1:11pm]_hc:I see no real disadvantage to do installing 'puredata' into /usr/lib/puredata [1:11pm]•IOhannes doesn't want to reread the archives [1:12pm]IOhannes:well, i agree with that [1:12pm]_hc:the extra objects need to be tied to the version of Pd [1:12pm]IOhannes:but there are so many things that have no disadvantage... [1:12pm]_hc:if pdextended sees puredata's extra, that messes things up [1:12pm]IOhannes:but take romans example [1:13pm]IOhannes:where should pd-gridflow install to? [1:13pm]_hc:but then also, if there are things that only work with 'puredata' and not 'pdextended', there is a place for them [1:13pm]_hc:common packages should go into /usr/lib/pd [1:13pm]_hc:and built against 'puredata' [1:14pm]IOhannes:yes, that's what i've written in my email; it's the only real reason i can think of [1:14pm]IOhannes:"that" being the "common" thing [1:14pm] BenLauDC left the chat room. (Quit: Leaving.) [1:14pm]IOhannes:but still pd-gridflow might depend on the version [1:15pm]_hc:of 'puredata'? [1:15pm]_hc:perhaps we could version 'pd' deps [1:15pm]_hc:if needed [1:15pm]IOhannes:but then .../pd and .../puredata don't solve much [1:16pm]IOhannes:as they still produce conflicts [1:16pm]_hc:still the same issue [1:16pm]IOhannes:gor good reasons [1:16pm]_hc:it would solve that still [1:16pm]IOhannes:gor=for [1:16pm]IOhannes:do you know anything that works with puredata and not pdx [1:16pm]IOhannes:that is not version-dependend? [1:16pm]_hc:the extra stuff in 'puredata' [1:17pm]IOhannes:i'm sure you can load puredata's extra~.pd_linux with pdx [1:17pm]_hc:it "works" but would not be the expected result for the pdextended user [1:17pm]IOhannes:even with different versions [1:17pm]_hc:if there is puredata 0.43 and pdextended 0.42 installed [1:17pm]IOhannes:yes [1:18pm]_hc:let's say miller adds 'prepend' to extra in 0.44 [1:18pm]IOhannes:then? [1:19pm]IOhannes:if the pdx user created [prepend] [1:19pm]IOhannes:pdx would first look for prepend in /usr/lib/pdextended [1:19pm]IOhannes:and fail [1:19pm]_hc:pdx user runs with no libs loaded by default [1:19pm]_hc:[prepend] means puredata's prepend [1:19pm]IOhannes:(because of missing namespace) [1:19pm]IOhannes:yes [1:20pm]_hc:so you agree that's a real problem? [1:20pm]IOhannes:no, still not so sure [1:21pm]•IOhannes is trying to become convinced [1:21pm]_hc:that's a real problem if its an incompatible prepend [1:21pm]_hc:like the pow~ issue [1:21pm]IOhannes:next pdx release, pdx will include prepend, and the problem starts over [1:21pm]IOhannes:but it's a different problem [1:21pm]_hc:sure [1:21pm]IOhannes:how is pow~ solved in pdx now? [1:22pm]_hc:miller's pow~ throws an error [1:22pm]_hc:with a warning message [1:22pm]_hc:that's the best I could think of [1:22pm]IOhannes:not sure i understand [1:23pm]IOhannes:what does the error/warning solve? [1:23pm]_hc:tells you the inlets switched [1:23pm]_hc:in a forceful way [1:24pm]IOhannes:but the object creates? [1:24pm]_hc:yeah [1:24pm]IOhannes:so the patch is still non-functional [1:24pm]_hc:not because of the error [1:24pm]IOhannes:though at least you get a warning [1:25pm]IOhannes:well, the warning doesn't fix the patch [1:25pm]_hc:for the next pdextended, I'd like to make 'vanilla' a libdir so people can choose themselves [1:25pm]_hc:then there can easily be vanilla-0.42, vanilla-0.41 [1:25pm]_hc:etc [1:26pm]IOhannes:though i love the idea, i'm not sure whether it's woth it [1:26pm]_hc:that makes the /usr/lib/puredata thing more important [1:26pm]_hc:I'm halfway there, pdextened 0.42 already has a vanilla with a bunch of objects in it

----------------------------------------------------------------------------

I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler