Hans-Christoph Steiner wrote:
Since you are also thinking about packaging, it would be good to open up a discussion about how to handle some things. If you plan on just packaging pd-vanilla, then its easy. If you want to support multiple versions of Pd then it gets a bit more complicated.
Yes, because they are incompatible.
Basically, libraries/externals can't be installed into 'pd/extra' because then the packages would conflict.
Huh? You can't have two packages installing the same file (but there are mechanisms to cope with this even then), but you can have different packages installing files into the same directory (/usr/bin/ for example).
I proposed /usr/lib/pd-externals/ as a place to install all packaged externals, so then you could have pd-vanilla, pd-extended, desiredata, etc. installed and they could all use the externals. Claude of pure-dyne had an objection to this, but he didn't follow up on the details.
It's broken by design.
Where is the guarantee that pd, pd-extended, desiredata, etc all have exactly equal binary API for externals? Some externals (that use GUI features, for example) won't work with desiredata while they work fine with pd. Also, some abstractions (that use [initbang], for example) won't work with pd while they work fine with pd-extended.
I suggest something like: /usr/lib/pd for pd, /usr/lib/pd-extended for pd-extended, /usr/lib/desiredata for desiredata. Otherwise you'll end up with a lot of broken-ness.
Claude
I tested multimodel yesterday and it works with perfect with zexture coordinats
Thank you Mr. Zmoelnig
your sincerely der.brandt
On May 17, 2009, at 9:46 AM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
Since you are also thinking about packaging, it would be good to open up a discussion about how to handle some things. If you plan on just packaging pd-vanilla, then its easy. If you want to support multiple versions of Pd then it gets a bit more complicated.
Yes, because they are incompatible.
Far from it. Yes, there are some incompatibilities, but mostly not. Unless pure:dyne is changing code from the pure-data SVN, we are using the same code built against the same API. They will be ABI compatible between pd-vanilla and pd-extended. As for desiredata, I don't really know, but I think Matju's aim is to keep it compatible.
Basically, libraries/externals can't be installed into 'pd/extra' because then the packages would conflict.
Huh? You can't have two packages installing the same file (but there are mechanisms to cope with this even then), but you can have different packages installing files into the same directory (/usr/ bin/ for example).
If all packages install into /usr/lib/pd/extra, then if there is a package that is not compatible with pd-vanilla, it'll be installed into the same place. Also, unless the objects that are normally in 'extra' pd-vanilla are packaged separately, each 'pd' package will want to install some of the same files into /usr/lib/pd/extra, which means conflicts.
So say pd-extended uses /usr/lib/pd-extended, but then all the library packages install into /usr/lib/pd/extra, then Pd-extended will look there, and then the second copy of the 'extra' files.
I proposed /usr/lib/pd-externals/ as a place to install all packaged externals, so then you could have pd-vanilla, pd-extended, desiredata, etc. installed and they could all use the externals. Claude of pure-dyne had an objection to this, but he didn't follow up on the details.
It's broken by design.
Where is the guarantee that pd, pd-extended, desiredata, etc all have exactly equal binary API for externals? Some externals (that use GUI features, for example) won't work with desiredata while they work fine with pd. Also, some abstractions (that use [initbang], for example) won't work with pd while they work fine with pd-extended.
The guarantee comes from the package, it includes the dependency of 'pd' (the generic virtual package for pdish things), 'puredata', 'pd- extended', and 'desiredata'. Most of the libraries that are packaged can easily be built against one, and used with the others. They are binary compatible. If a library uses [initbang], then that package would have a dependency on 'pd-extended' rather than the generic 'pd'.
So there could be a folder for the 'pd' dependencies that is shared by all, like /usr/lib/pd-externals. Then a package that relies on specific features would have a dependency on that specific version and install into its 'extra' folder. This isn't the only way to handle this for sure, I am certainly open to suggestions.
I suggest something like: /usr/lib/pd for pd, /usr/lib/pd-extended for pd-extended, /usr/lib/desiredata for desiredata. Otherwise you'll end up with a lot of broken-ness.
Claude
That makes perfect sense. The question is then, how do you then package 'zexy', for example, so that it can be used by 'puredata', 'pd- extended', and 'desiredata'?
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
-
brandt＠subnet.at -
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmölnig