[PD-dev] adding standard install paths to the 'puredata' package

[Frank Barknecht]

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> But that means the definition of /usr/lib/pd has to be changed.  We discussed
> these this at the last PdCon, and there was agreement on the fact that the
> three directories are needed.  So then we have three directories that overlap
> the meaning of the original /usr/lib/pd:
>
> 1. a /usr/lib directory for objects that work for everything that  
> provides 'pd'
> 2. a /usr/lib directory for objects that work only for 'puredata'
> 3. a /usr/lib directory for objects that work only for 'pd-extended'
>
> I am ok with keeping /usr/lib/pd as the first directory since it matches 
> the virtual package 'pd'.  
>
> (Previously we'd decided on /usr/ lib/pd-externals as the name for the first
> directory).    In terms of  the packaged libraries, using /usr/lib/pd for the
> first directory means the existing ones don't have to change unless they are
> incompatible with Pd-extended/DesireData.  

I think, this makes sense and I'd go that way as well. But not only because
of the name of the virtual package, also because "pd" is just *the* name for 
this, like "X11" is *the* name for everything regarding X software, even when
no package carries that name anymore. 

Now that we have new players like maybe desiredata, they can and should use 
their custom directories if they need to, but this should not directly affect the old
ones. 

A different issue is version changes. Here a possibility could be to follow
examples like Vim or Python, which use a versioned subdirectories like 
/usr/share/vim/vim71/ or /usr/lib/python2.5/site-packages.


> But that means changing the 'puredata' package 
> to use /usr/lib/puredata for the stuff that comes in pd/extra (i.e. 
> bonk~, etc).

This I don't understand. They are externals, but they work and come with the
original, vanilla Pd. In my opinion they can and should stay in /usr/lib/pd

Ciao
-- 
Frank