Hi, I'm packaging GStreamer (http://gstreamer.net/). It has a somewhat small core but also a very large number of plugin wrappers for various libraries. The approach I took was to package everything in small pieces: core libraries, dev packages, apps, docs, utils, plugins, etc. I put all the dependency free plugins in one package. Then a whole lot of separate packages for plugins with specific dependencies: aalib, mad, mpg123, alsa, arts, cdparanoia, etc etc. These are all independent of the core and not required if users/apps don't need them. After I add support for recent additions of SDL and gnomevfs plugins the total package count will be close to 30! And it's only going to grow from there.
Putting -all- the plugins in one package would be nice but I don't know how happy users will be if they are forced to download a truckload of extra libs they may not want. I'll probably add a top level pseudo package depending on all the other packages just for user convenience. It seems this is how things should be setup but I don't want to scare off or confuse users. Adding new plugins is automated enough that maintaining it all won't be too bad. So my question: is this package explosion acceptable? My current work-in-progress packaging info is in GStreamer CVS though it may be a bit out of sync with latest code. -dave -- David I. Lehn <[EMAIL PROTECTED]> | http://www.lehn.org/~dlehn/ Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA
