[PD-dev] debian installation paths for Pd(X)

[Hans-Christoph Steiner]

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