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.
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.
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).
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).
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.
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.
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?
these are just a few arguments that i think are stumbling blocks for your proposal. its not to say that its a dumb idea, but perhaps a little simplistic and something which has already met a lot of conentious discussion on this and other forums.
but if you care to go over some of your ideas with a bit more detail we may find something interesting to work with. -- dmotd.
Anderson Goulart wrote:
Hello IOhannes,
thanks for your answer...
On Mon, Sep 21, 2009 at 4:08 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
Anderson Goulart wrote: Hello all, puredata-ext-XX - package containing a single external puredata-abs-XX - package containing a single abstraction why do you want to separate them? how does a "single external" differ (substantially) from a "single abstraction"? (esp. since .deb takes care of platform-in/dependency)
Well, this is just an ideia and we can decide to use names like puredata-xxx, where xxx is the name of external/abstraction. What I want here is to discuss the conventions about packaging things related to Pd.
do you really want to distribute a _single_ file with an entire .deb or do you rather mean "library"?
Maybe we can distribute a "library" if those externals/abstractions are related. But if they are different, with different upstream authors, with different dependencies and different funcionalities, I think distribute an entire .deb is better than put it together in a library.
how does this integrate into the already existing debian infrastructure for Pd? e.g. with naming schemes like "pd-zexy" or "pd-gem" (that is: why do we want to reinvent the wheel?)
I am not a debian developer, but I am sure we can talk to them to upload all packages to the official repo. The naming conventions are just suggestions and we can use pd-xxx instead of puredata-xxx. The main idea of this email is to separate pd-extended into some .deb packages to become more clear and easier to maintain to many architectures and distribution versions.
bye, global