[PD-dev] adding standard install paths to the 'puredata' package

[Hans-Christoph Steiner]

On Dec 3, 2009, at 9:28 PM, Claude Heiland-Allen wrote:

> Some quick comments..
>
> Hans-Christoph Steiner wrote:
>> By the way, is anyone from pure:dyne listening?  It would be great  
>> to have some input from you.
>
> 1. The paths stuff: the status quo is fine, I don't understand what  
> you are trying to fix at all, apart from disruptive "change for the  
> sake of change" to make a name more perceptually uniform - wtf does  
> that solve?

The problem was outlined in this thread, and in previous discussions.   
How to handle the objects in 'extra' and the versioning requirements.   
More uniform naming is only an added benefit.

> 2. it was taking too long for us to get packages into Debian
>
> 3. Puredyne (Ubuntu Karmic based distro) packages are here:
> https://launchpad.net/~puredyne-team/+archive/ppa
>
> 4. The Puredyne pd-foo external packages "Depends: puredata" (afaik).

For them to become generic packages that work with 'puredata',  
'pdextended', 'desiredata', they would need to depend on 'pd'.

> 5. Maybe it would be better for puredata and pd-extended to both  
> "Provide: pd", but then pd-extended will have a long "Conflicts: .."  
> list, which is a pain for things like pd-gridflow "Depends: pd-gem,  
> puredata" which means Puredyne pd-gridflow won't work with Pd- 
> extended unless Pd-extended "Provides: pd-gem", then things will  
> crash if the respective Pd ABIs are different, etc...

I think this assumes that Pd-extended is a monolithic package, which  
it will not be.  I think that 'puredata' and 'pdextended' both can  
provide 'pd' and be installed into separate directories.  I am ok with  
making 'puredata' use /usr/bin/pd and 'pdextended' use /usr/bin/ 
pdextended.  /usr/bin/pd could be handled by /etc/alternatives so that  
people can provide which flavor is tied to the 'pd' command.

> 5.b. There must be a good elegant technical solution out there  
> somewhere, but so far the "accidental workaround" of Puredyne's pd  
> and externals packages basically conflicting with Pd-extended  
> completely, hasn't caused too many problems in the wild: either have  
> Puredyne puredata and modular externals, xor have Pd-extended  
> monolith - choose your poison..


AFAIK, no one thinks the big monolithic package is a good idea for  
Debian/Ubuntu.  That's why we are having this discussion.  I think  
this path issue is really the only think I would add to the pure:dyne  
approach.  The other would be building things as a single-binary- 
single-object format for objects in externals except objects that  
won't work in that format (i.e. the objects like [>~] or [/~]).   
Aliases can be made to work in this format too, I'll do the work there.

.hc


----------------------------------------------------------------------------

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie