On Wed, 2007-09-05 at 16:59 -0500, Les Mikesell wrote: > Back to the beginning with this argument: if you are only planning to > dlopen() libvorbis in the presence of ogg files there's no particular > reason to expect it to be necessary at all, let alone a particular > version of it. In the course of the discussion, certain information got blurred. First of all, the idea was that for optional modules in certain packages, it's desirable from a packaging perspective for the modules to be separable from the main package (as in the case of apache httpd, php, perl and gstreamer-plugins). Only if a library is optional and already supports separationg from the main package. If it's required (no point for having an Ogg vorbis player be separated from the vorbis library, right?), then that's fine. If it's optional but the software isn't written so that the optional module can be easily separated, then that should first be taken up with the software developer ... or fork. In the cases where the modules are optional and separable (because they're supported by the language ... Perl, python and java modules are separable by nature. C modules can be separable if they're dlopen(3)'d as opposed to ld(1)), I'm hoping that the packagers take advantage of this and package them separately (which is already done in a lot of packages). A couple of places where it COULD be done are a) gstreamer-plugins and b) kernel modules. I won't even go into kernel modules as even now there's a push to even make it even more monolitically packaged. gstreamer-plugins COULD be separated. They're only packaged as gstreamer-plugins-(base|good|bad| ugly) because that's the way the developers packaged them. Technically, a gstreamer-plugin-good.src.rpm could generate gstreamer-plugin-vorbis, gstreamer-plugin-<whatever> and could all be pulled in by the virtual gstreamer-plugin-package-good. As I was contemplating on actually doing this, it occurred to me that I don't know how to do optional packaging in RPM spec files based on the existence of the lib*.so files. (no support in rpmbuild that I'm aware of, but I'm no expert.) Anyway, as the original poster who brought up this thread, I'm not even targetting specific packages but was wondering more about philosophy. If it's written down somewhere that Fedora developers should keep an eye out for making packages Modular so that distro-spinners have more flexibility, then perhaps that would help devs down the line. That's all. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
