Goal: Increased Modularity?

[Richi Plana]

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