> pd-extended could be assembled from parts as a > meta package, there's no issue there.
I guess my point is that, if I download the pd-extended tarball, it is not easy at all to assemble it as a series of parts, not as easy and efficient as it could be. At the very least, I think there needs to be some housekeeping done. > 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. Correct! I think Anderson and I are complaining strictly as packagers. > 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. All I'm asking for is increased modularity, which is more than just the debian way. Though admittedly I have no idea how Windows installers are built, but I don't think it would be difficult to have a check box or something that says "Install Everything! (Recommended, seriously. Default.)" What I'm really seeking is improvement on modularity for the _build_, not necessarily the package. > 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'll have a look at these. (I'm working on Gentoo :) > 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). Yesss. This is what I want. I just really think pd-extended should be assembled, virtually, in package repositories rather than in sourceforge (perhaps with the exception of windows and mac?) > 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. Agreed. I can't conceive that what I'm advocating would cause problems for Windows and Mac package creation, but maybe I am biased just from ignorance. > 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. Sounds great. > 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. Now we're talking. > 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. Yes. And I have really been picking apart the current build mechanism in the Gentoo ebuild I have been working on, which is bad, but necessary to make it really modular. I would be happy if I did not need to do this. > 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!!). Awesome. Maybe I'll just shut up until I see what you've got going :) _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev