[PD-dev] proper debs (pure:dyne+pd-extended = good)
hans at at.or.at
Wed Apr 22 02:08:37 CEST 2009
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  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.
>  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-
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/
"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
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-
There is no way to peace, peace is the way. -A.J. Muste
More information about the Pd-dev