Hi,
Hans-Christoph Steiner wrote:
On Apr 21, 2009, at 3:09 PM, Claude Heiland-Allen wrote:
Hi Hans, all,
Hans-Christoph Steiner wrote:
[snip]
The key here is to make sure that the library packages can work with separate versions of pd. Something like 'puredata' and 'pd-extended' which both provide 'pd' but can coexist.
Sure, that's possible with Debian packaging.
That means the libraries should probably be installed into a standardized shared location, so maybe instead of /usr/lib/pd, use /usr/lib/pd-externals, which would match ~/pd-externals/ and /usr/local/lib/pd-externals for user-installed stuff.
WTF?? This is exactly the kind of pointless disruptive change that I was arguing strongly against here:
our job as packagers (in the .deb sense) isn't to save the pd universe with some grand architecture, but simply to make packages available for users :)
[snip]
Also pd-extended's policy of splitting every library into tiny pieces solves one problem but causes others, so I think it was slightly premature to do the splitting until the other issues are fixed.
[snip]
When you guys encounter problems with it, I would greatly appreciate feedback so that those problems can be addressed.
[>~] etc
[snip]
With abstractions the situation is worse. If you make your abstraction called [threshold] and include it in the same folder as your project. Then you use a patch that uses smlib's [threshold] and close it. Reopen your patch and [threshold] will be the smlib one, _not_ your threshold.pd. Or say Miller adds [threshold] to Pd-vanilla, same story, except there is no way to ever load your threshold.pd, unless you stick into a folder and call it [myfolder/threshold].
Sure, but that's nothing to do with Debian packaging.
"Use it like it is because its like that" seems like surrender to me.
We're talking about packaging for Debian, not saving the world in one jump. When the issues are improved (by the upstream authors), they make a new upstream release, then the packager can update the Debian package.
When you link libraries into one file, then you cannot address any of these name conflicts.
True, but [>~]
A big part of these problems with Pd-extended comes from having so many libraries loaded by default. I think that none of the libraries should be loaded by default, I am guessing that's how pure:dyne does it.
The live distribution has a ~/.pdrc that loads most things.
Yes, this is a definitely something to think about. These days, I am thinking more and more that we should make it easy for people to package and release libraries themselves, and make it really easy to install libraries. That's the first step.
Yes. We (as packagers) can only package what is there.
Once we have a whole bunch of Pd externals in SVN that are set up with clean .deb building code, there will be lots of examples for people to draw from when packaging their own libraries.
You can use "apt-get source" to get some examples from the pure:dyne repositories already.
Personally I'm not in favour of keeping debian/ folders in the same svn as the upstream source code, as they have rather orthogonal purposes.
If the aim is to make official debian packages, I think it makes sense to maintain the debian/control, etc files in the main Pd repo: pure-data SVN.
Why? The Pure-data repository is for Pure-data things, and Debian has its own infrastructure for Debian things.
upstream authors (write externals) | | upstream source repository V upstream maintainer (tidy up externals for release) | | upstream source release V ------ upstream responsibility ends here debian maintainer (packages release for debian) ------ debian responsibility begins here | | debianized source release V debian build system / repository (builds for debian users) | | debian packages V user "aptitude install" (gets to enjoy the externals)
Thanks,
Claude