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
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
