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:
- 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