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.
.hc
----------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
