tim, yup with you all the way here, i've been chatting a bit to mescalinum about his work with gentoo too, and i'm pretty sure we're all after the same goal.
cheers, dmotd Tim Jones wrote: > > 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