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.
- 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.
it was taking too long for us to get packages into Debian
Puredyne (Ubuntu Karmic based distro) packages are here:
https://launchpad.net/~puredyne-team/+archive/ppa
- 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'.
- 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