On Jun 23, 2006, at 7:49 AM, geiger wrote:
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
I definitely don't have an interest in fixing things that are not useful. That is certainly not the aim of Pd-extended. So much stuff is included because a) there is a ton of good code available for Pd, and b) people use this stuff. Before, if someone posted a patch where they used some non-standard externals, it was always a major chore for other to set up the externals so that patch worked. If everyone is on the same install, that problem goes away.
Yes, its a big package, and yes there is a lot of crap that is included. But these days, hard drive space is far cheaper and more abundant than Pd developer time. So it doesn't really seem worthwhile to spend much time removing cruft if it doesn't get in the way, and its safely tucked away in a libdir, where it can't do any harm to people unless they try to use it.
Another thing about a common build system is that a lot of the maintenance and debugged is then shared across platforms. This saves a lot of labor. I think that the debian packages would be less maintenance if their build system was pooled with Pd-extended, especially if you include pdp and pidip and others that aren't currently part of the "official" debian packages.
If I bundle up everything it will be pretty hard to get it into a state where it can enter the debian repository, especially for things like pdp (which is in debian) and pidip, which have their own build system, and what pd-extended does is mainly calling that, if I am not wrong.
If the packages are split up I can work on the problems separately, while other parts that are less complicated to get going can easily go through quality control.
The Pd-extended build system should be able to handle this right
now. Each section is easily buildable on its own by doing: make
ggee, make zexy, make pdp, make iemlib, etc. And it is quite easy to
redirect the install location of make pdp_install, make zexy_install,
etc.
I also like to have the possibility to only install pd, and not hundreds of externals which I won't use, and which I think noone
should use and which just use up disk space.
There is undoubtedly a lot of cruft. Part of what I think we should
do with Pd-extended is to make a standard way of deprecating cruft.
But that takes a lot of work. So in the meantime, Pd-extended ships
with a lot of cruft.
The way Pd-extended is now is by no means a finished product, its
just one of the stepping stones to a Pd platform. I think its time
to stop wasting time making separate build systems and distros for
each platform. The amount of time that people have wasted on issues
due to the separate distros is massive. The amount of time people
have to wait because the package is 25 megs bigger than it should be
is not very big. We can then put that effort into going forward on
all platforms.
For example, I have already started the process of building a farm of
servers for automatic nightly builds for a number of platforms. This
will help us catch problems and save us a lot of time making test
releases. Having a common build system means that when a problem is
solved on one platform, its most likely going to fix that problem on
all the rest.
If someone else did the work, would you be willing to accept it as the standard Debian packages?
I am not in the position to accept standard Debian packages, if you
ask if I would upload such a package to Debian, I would say probably. It depends on the quality of the package (see above) and if the person who packages it is reliable enough.
Once we have the automatic nightly builds setup, that should catch a
lot of problems. Moving it to Debian proper shouldn't be a big deal
then.
.hc
Günter
.hc
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore