hello,
just my two cents, not haveing read all the threads...
Personally, I think that the Debian packages should reflect the other Pd-extended builds and just be one package. I could see separating out the Pd core, so that you could use different versions with the same pd-extended externals, docs, etc. but that might cause problems since some externals might only work properly with the version of Pd that they were compiled against.
I just don't see any advantage to having all of this stuff separated into separate packages. For example, Gem is useless without Pd, and if its not being used it does no harm, it just takes up disk space.
It takes up much more because of all the dependencies it has. And dependencies are not only something which takes up disk space, they are something which can and will break on upgrades.
If someone is not interested in the video side of Pd at all or if someone wants to run Pd on an X-less webserver, then there would be no need to install Gem and all its dependencies. Without Gem and pdp, an externals package's dependencies would be supersmall, but including Gem and pdp you need a really huge list of packages to install for two externals, that are totally useless to maybe half of Pd's usersbase (just a guess for the sake of the argument).
And I'm not even mentioning build-dependencies yet, which should also be taken into account at least on Debian and probably Gentoo.
That's why I would prefer that Gem and pdp go into their own packages (and that pd-extended reflects the Debian builds and just be several packages ;) and users can make their own choice. (And they chose Firefox and Thunderbird over Mozilla.)
The dependencies argument is a valid one, but that will be a lot of work to setup and maintain, it seems to me. Are you then going to have to make pd-ogg, pd-mp3, pd-speex, pd-libsndfile, etc?
Audacity is a good example, its a similar program. The audacity package has a long list of deps on top of the minimum: libflac++5, libflac7, libid3tag, libmad0, libogg0, libsndfile1, libunwind7, libvorbis0a, libvorbisen2, libvorbisfile3. Ardour has an even longer list: http://packages.debian.org/unstable/sound/ardour-gtk, and ffmpeg has a decent list too: http://packages.debian.org/unstable/graphics/ffmpeg
I think that Pd is much closer to Ardour/Audacity/ffmpeg than Mozilla, especially when you consider that Firefox and Thunderbird are standalone apps, while none of the Pd sub-packages will do anything without Pd.
What is if I want my own GEM tree and not the debian one, because GEM has a lot of compilation option, then it would be nice just not install Gem to not get mixed with the the debian.
A good example of many debian packages is python or zope, where every product is zope-gruf, zope-squishdot, ....
other poeple can add their packages too in the same manner.
But I am probably not going to do the work, so its just my opinion.
thats a good point,
... maybe would be easier for you not to package them, since their maybe different dependencies for video libraries, which cant be used parallel... (there was such a case some time ago).
... maybe its better if there are big projects like GEM, the packages are made by themselves, maybe they make some own versions and rythm for release with different dependencies.
mfg winfried
.hc
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev