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:
- 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.
.hc
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic