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
--
http://claudiusmaximus.goto10.org
http://puredyne.goto10.org
http://goto10.org
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev