[PD-dev] [PD] packaging pd and friends WAS: GIT repo

[Hans-Christoph Steiner]

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