[PD-dev] proper debs (pure:dyne+pd-extended = good)
claudiusmaximus at goto10.org
Fri Apr 24 12:40:42 CEST 2009
Hans-Christoph Steiner wrote:
> On Apr 21, 2009, at 3:09 PM, Claude Heiland-Allen wrote:
>> Hi Hans, all,
>> Hans-Christoph Steiner wrote:
> 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
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 :)
>> 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.
> When you guys encounter problems with it, I would greatly appreciate
> feedback so that those problems can be addressed.
> 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
>> 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
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
upstream maintainer (tidy up externals for release)
| upstream source release
------ upstream responsibility ends here
debian maintainer (packages release for debian)
------ debian responsibility begins here
| debianized source release
debian build system / repository (builds for debian users)
| debian packages
user "aptitude install" (gets to enjoy the externals)
More information about the Pd-dev