Goal: Increased Modularity?

[Bill Crawford]

On 04/09/07, Bill Nottingham <notting at redhat.com> wrote:

> > Why is it that so
> > many packages can't stand alone without libvorbis? I know that some of
> > the packages NEED libvorbis, but for many, shouldn't it be optional and
> > something that isn't required to be compiled against (think dlopen(3)
> > instead of ld(1)) like gstreamer-plugins-* (which all seem to require
> > libvorbis)?
>
> dlopen will cause you to break at runtime instead of buildtime if
> ABI changes - that's not good.

Eh? You have a plugin that's linked to libvorbis, and then load *that*
at runtime; and you can rebuild the plugin independently of the main
application if the libvorbis API or ABI change. The point is to make
the need for (libvorbis is probably not the best example) the plugin
optional. The plugin has all the right dependencies so it depends on
the correct soname etc etc.

There is a good use case, and that was mentioned further down: pulling
in all the gstreamer-plugins packages gets me a shedload of
dependencies for various sound + video libraries that I never, ever
use, and that in combination with all the work-related stuff I have on
my machine here pushed me over the limit for prelinking everything
(prelink -av reported being unable to find an address slot for
something). Before everyone chimes in with "use -m" ... that kinda
makes prelinking pointless when a lot of libs are plugins that are
loaded dynamically, because prelink can't tell when they're used in
the same application based on the dependencies between the binaries
and libraries ...