On Apr 24, 2009, at 6:40 AM, Claude Heiland-Allen wrote:
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:
Could you illustrate the disruption? ~/pd-externals/ and /usr/local/
lib/pd-externals (and their equivalent for each platform) was included
starting in Pd-extended 0.40.3 and it works very well to have a
standard location for user-installed files. Having a standard
location means we can have clear documentation as well as other
benefits. Ideally, all versions of Pd would use the same locations to
avoid disruptions and confusion, so I submitted a patch to Miller for
this.
How then do you propose to support installing externals for multiple
'pd' packages? The 'extra' folder is really tied to a given version
of Pd. Its one thing to complain about the 'pd-externals' idea, but
its just a complaint unless you propose a solution, or at least
describe the problems with it. I think that most packagers actually
make many such changes to fit with Debian Policy. This is a good
thing IMHO, it is one of the big strengths of Debian.
For example, a typical change that would also change the standard Pd
paths is installing the HTML docs into /usr/share/doc/puredata instead
of /usr/lib/pd/doc/1.manual. I think a proper Debian package of Pd
should do this as well. I think that many Debian packagers would
argue that no docs should be in /usr/lib/pd. Plus following Debian
Policy, it should be /usr/lib/puredata anyway, since the package name
is used as the identifier as well.
I think we can easily manage such changes without disruptions with
some careful attention.
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
Yes, I think though IOhannes' valiant efforts, we have learned that we
need to have a special case to deal with objects that include the
characters < > / \ | * ? " : (these are not supported all
filesystems). For those, they can be loaded from a single file. I
think this could be supported in a nextgen libdir based on IOhannes'
idea for having a binary shared library that is loaded when the
library is loaded. Then we can have a single folder that can have a
shared binary library for the external, the possibility to load
objects with < > / \ | * ? ", abstractions included in the same
library, and the help patches also included in the same library.
As for characters that can be on the filesystem, but not in C
function names, I think we should just have a generic setup() function
for those, like Max/MSP does (tho there is called main()).
I tried to sum up the years of discussion and what I think is the
beginnings of a consensus for a solution in my PdCon paper. I would
love feedback on it.
http://at.or.at/hans/Let's_Make_Libraries_-_PdCon3.pdf
[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.
The decision as a pd externals packager is which library format to use
for externals which have more than one feasible format. That's where
this comes into the packaging discussion.
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.
FYI: Miller and others consider the .pdrc deprecated, so the package
should use .pdsettings, IMHO. But that's not a big deal. The Pd GUI
only uses .pdsettings.
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)
Here's how I see it, there are three general cases:
- Many of us are authors and packagers, so why separate the debian part?
- there are many authors who are not packagers but use Debian. I
imagine that we could convince such authors to maintain the packaging
code once its setup. debian/control and debian/rules are not hard to
read and edit once they are setup, so I think we could get many people
to maintain their own packages if the debian code was in the same place.
- Then for other situations I imagine it would often make more sense
to maintain the packaging code in a different repo.
.hc
Thanks,
Claude
--
http://claudiusmaximus.goto10.org
http://puredyne.goto10.org
http://goto10.org
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
