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

Hans-Christoph Steiner hans at at.or.at
Thu Dec 3 19:11:11 CET 2009

On Dec 3, 2009, at 9:22 AM, Frank Barknecht wrote:

> 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

The problem is versioning.  One of the goals of Pd-extended is to be  
compatible with the same version of Pd-vanilla, i.e. Pd-extended  
0.40.3 can run anything that Pd-vanilla 0.40.3 can.  I imagine that  
desiredata has a similar goal, but maybe not.  The objects in 'extra'  
are part of what Pd-vanilla 0.40.3 provides.

So if the objects in extra come with the 'puredata' package and are  
put into the common /usr/lib/pd directory, then the 'pdextended' and  
'desiredata' packages would use the versions that come with  
'puredata'.  So that means they would need to be removed from the  
'pdextended' and 'desiredata' packages.  That's not a big deal, I am  
ok with that.  But the problem is that if 'puredata' gets updated to  
0.43 while 'pdextended' is still at 0.42, and 'puredata' puts the  
'extra' externals into the shared directory.  Then 'pdextended' can't  
be 0.42 compatible anymore.

One idea is to package Pd vanilla's 'extra' separately, i.e. 'pd- 
extra'.  Then 'puredata' can Recommend 'pd-extra' and 'pdextended' can  
Conflict with 'pd-extra' and I can make versioned packages for  
'pdextended', ie 'pd-extra042'.  Another is to have the extra folder  
from 'puredata' in /usr/lib/puredata.

By the way, is anyone from pure:dyne listening?  It would be great to  
have some input from you.



Access to computers should be unlimited and total.  - the hacker ethic

More information about the Pd-dev mailing list