So with a couple of perhaps narrow-minded rants out of the way, I would like now to respond to dmotd.
> > i guess i understand where you're coming from and > in some ways i think you are right, however > packaging debs is not as simple as it seems and > with the sheer size of the externals repo what you > are suggesting would get quite unmanageable. > It might be a lot of work for one packager, but like any complex task it will be easier if you break it up into smaller ones. The Makefile in the externals directory of pd-extended seems unmanageable, to me. Have I misunderstood you here? I think modularity will help us all retain sanity in both implementation and maintenance. > > for the record, i am currently working on a > slightly revised build system and part of the aim > of that is to modularize the building process, so > that assembling pd as a series of parts will > become easier and more configurable. automating a > set of debian rules would hopefully be a lot less > time consuming once this work is complete. > I would be interested in details. > > this may knock over a part of the problem, but > there are a lot of libraries that require less > generalized appoaches and need careful attention > from a packager (which can become a time consuming > role). > Okay. All those Debian tools and Gentoo eclasses have functionality to deal with tricky packages. If the library needs a lot of configuration, then it may not be a problem with the library or its build system, but a necessary challenge to the packager. Even now some externals fit nicely into the template in the Makefile and some need customization by there very nature. > > this is part of the reason why pd-extended is a > very successful package - it knocks out a lot of > the maintenance hastles by automating as much of > the build procedure as possible, and although as a > whole it is quite monalythic, the same set of > objects can be reliably assumed across each > platform (or in linux terms each variety of > distribution). it's not perfect but it makes sense > for most people - and many thanks to hans for > getting it this far (its a pretty thankless job). > Yes, thank you Hans for getting me some form of pd-extended, thus giving me the motivation to post here at all. > > perhaps what should be asked is what is required > from pd to make it a full featured language for > people to practically use it for whatver meets a > general set of needs? for many people what miller > packages as his own 'vanilla' set is all that is > required and everything else is extraneous. for a > lot of people with complex goals that just doesn't > cut it and extended is necessary to work beyond > pd's own limitations. > I think extended is a good idea. I just think it would be better implemented in distribution repositories as meta-packages than on the source side. > > or pehaps pd could go down the path of perl/cpan, > php/pear etc, where extra non-base libs are housed > in a dedicated on demand server where users can > automagically fetch / compile and install extras > outside of the confines of a package manager. > There are a lot of externals, but not that many :) And in that future, I would look at making something like g-cpan on Gentoo, which can build a Perl module from cpan and still have it appear in my portage tree, even for those modules which have no ebuild already written! (It is essentially a wrapper for the cpan shell.) > > or do you want there to be categorized libs for > different areas of programming, what should be > installed by default with the meta package, and > what happens to objects that don't neatly slot > into a category - or worse fulfil a number of > categories? > Again I think what gstreamer does might be interesting, and worth closer attention. They group their plugins based on stability/maturity. _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
