On Apr 21, 2009, at 3:09 PM, Claude Heiland-Allen wrote:
Hi Hans, all,
Hans-Christoph Steiner wrote:
I don't know if any of the active pure:dyne packagers are on this list, but I thought I'd try. From what I have seen, it looks like pure:dyne is doing a much better job of making .deb packages than Pd-extended. I would be great to 'officially' merge efforts so that we don't duplicate work.
Sure, we strive for high quality packages. Regarding duplication of work, the pure:dyne wiki [1] has some packaging tips, the main thing is to get a good source.deb that can then be built for any Debian- based distro. We have a pbuilder machine ready to compile packages, if anyone wants to help broaden the range of pure data related packages in pure:dyne (and eventually Debian main) you are more than welcome to join in the effort.
[1] http://code.goto10.org/projects/puredyne/wiki/DevLounge#SoftwarePackaging
Regarding pd-extended, pure:dyne is based on pd-vanilla, which we've found to be quite stable, while pd-extended seems to have more experimental patches that don't always work out.
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. 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.
Then you can keep transparent boxed, bold fonted Pd in pure:dyne ;-) and others can choose a different look. I think basically, Pd-vanilla is barely maintained on Windows and Mac OS X, and is maintained on to work well on a stripped down GNU/Linux setup. Pd-extended aims to feel native on the most common platforms: GNOME, Mac OS X, and Windows. I think we've done a lot of good work along those lines. AFAICT, pure:dyne aims to be a stripped down GNU/Linux install, so it makes sense to use Pd-vanilla.
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. pure:dyne policy as far as there is one is to build the way the author(s) intended, resulting in a mix of libraries and single- object externals - but 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 :)
When you guys encounter problems with it, I would greatly appreciate feedback so that those problems can be addressed. The library format came about to address rear world problems. For example, using [mylib/ myobj] is currently the _only_ way to ensure that you get the object that you expect, regardless of whether its a .pd_linux or .pd. And [mylib/myobj] works with _any_ version of Pd back to 0.30 or before. This is quite important when making libraries that don't break with each new release of pure:dyne or whatever. The introduction of [pow~] to Pd-vanilla 0.42-4 demonstrated this point.
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].
"Use it like it is because its like that" seems like surrender to me. I think we can solve the hard problems if we try. Two steps forward, one step back is an inevitable part of the process. When you link libraries into one file, then you cannot address any of these name conflicts. I am happy to settle on using only what works now, but since pure:dyne is only Linux, [declare -path] and [declare -lib] work now, for example.
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.
Then we can make some really nice, proper packages and get them into Debian.
Makes sense, that's one of the key aims of pure:dyne too.
DebConf 2010 is in NYC, and I'll be helping to run it, so it would be great to have all this in Debian by then. Plus, it seems that Guenter has less time for the Debian packages, so things like the pd-externals package has lapsed.
That sounds like a good target. The pd-externals package is long obsolete (last updated 2004 iirc).
It seems to me that the next step would be to get the pure:dyne stuff into pure-data SVN, then make any tweaks to it to make it work with Pd-extended too.
We're more than happy to be good packagers and report bugs upstream, with any build patches required, but ideally there would be more upstream releases of known-quality code - currently it is still a bit hit-and-miss for some externals/libraries to know if there are unfinished pieces of code that will be fixed the next day or two, which acts as a disincentive for packagers to put the effort in to package from the svn.
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. 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.
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.
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste