nice to see a lot of discussion, i can't fathom replying to the various threads happening here as i am fairly time poor at present, but i thought i'd take the time to make my position as clear as possible before getting mixed up with any particular argument. apologies if i become a bit verbose!
so, lets just take a quick step back -
debian is one single operating system and packagers for debian can package pd in any way they wish, sliced, diced, recombined or with a flight simulator if they choose.
pd-extended could be assembled from parts as a meta package, there's no issue there.
as long as a user of extended on windows or osx can run their patch on a debian linux machine without a diminished experience then there should be no concern for how their version of extended was assembled.
so this i am all quite happy with!!
but, while the debian way is good for debian, its not the same fit for other environments. a user of windows doesn't have the same packaging comforts as apt-get and feels far more comfortable with an assembled installer, sure they could pick and choose their parts, but part of the luxury of extended is that its mostly all there and from a new user perspective this makes it instantly more rewarding than a blank canvas with hundreds of unknown installable modules.
but there are alternatives to extended.. planet ccrma has been a very reliable package set for a number of fedora users and i think this may be on a similar tangent to what both anderson and tim are proposing here for debian. similarly pure:dyne maintains their own version of pd, but in a different manner - also worth looking at.
i too agree that a monalythic build system does not make sense for long term maintainability, and makes pd as an environment far less configurable for specific needs - but i still support the existence and sustained efforts at packaging pd-extended, it just can be assembled better with greater modularity (making it a template of sorts).
what is important is that pd and its externals build evenly for the multitude of different platforms and that there is no bias towards individual operating systems. this is a balance that hans has very carefully respected with extended, iohannes and co have maintained with gem and what miller generously started with pd.
and that's why i am working on reshaping the existing build environments to become more modular, in which there is a method for building each lib as a self contained vessel from its own directory (tarball or whatever), while allowing each lib to be tightly woven into any number of custom builders seamlessly.
the inspiration is not mine and the initial groundwork was conducted by IOhannes and hans as a proof of concept demonstrated in the ext13 library (as well as motex and apple). i have been working on methods to make this template more managable for complex projects, better integrated into modular build *systems* and simpler to engage with for both newbies and devs alike. it should also make creating custom maintainer scripts much simpler.
i am not so concerned with any particular packaging system, what i am interested in is a simple configurable modular system that builds and installs source into a given tree / jail or whatever you like to call it, in the same manner for each target platform, while also providing useful tools for gathering information and tests for libs, objects and reference material.
what package maintainers do to integrate their needs is entirely up to them, but should be done in such a way without touching the behaviour of the overall build mechanism, rather simply extending its functionality through modular scripts and wrappers.
debian is one world view, its one i have used before, but not one i subscribe to currently myself, so please excuse my naivety when it comes to the inner workings and build semantics of a debian machine. i am however, cautious when it comes to mixing ideologies (or stubborn attitudes) of a certain 'way' with a system which should ideally provide simple navigation for a number of 'ways'. as long as there is respect for different methods then the debian gods can also get their way ;)
anyhow, i have been making steady progress over the previous weeks and i should have a snapshot ready shortly for perusal. if you want to talk directly about my work on the buildsystem i frequent the #dataflow channel of irc.freenode.org along with hans and a number of others. sorry i can't be more explicit with what i am assembling but it's still a bit of shifting target. i also have a dayjob - so this work is divided around scattered freetime so i hope it doesn't seem painfully slow, there'll be something to digest and potentially hack about with soon, so patience is appreciated. my methods may be rubish too, but i have given it a fair bit of consideration, and so too have others, so in this case i think improvement is a better solution than straight up reinvention (but its always exciting to be proved wrong!!).
thanks! dmotd