Goal: Increased Modularity?

[Richi Plana]

On Tue, 2007-09-04 at 12:57 -0400, Bill Nottingham wrote:
> Richi Plana (myfedora at richip.dhs.org) said: 
> > For instance, if I desired to come up with a spin that doesn't have
> > Sendmail, why must I give up fetchmail, mutt or tor?
> 
> Because they *require* a MTA to deliver/send the mail, at least in their
> default configurations

Well, I figured that they are required because of their default
configurations. But would Fedora be interested in changing it if
modularity were indeed the higher goal?

Besides, you said it requires an MTA. Would an effort to add the ability
to detect the availability of /sbin/sendmail in the above-mentioned
packages and use it if available or speak SMTP over port 25 if not be
desirable? Packages like evolution and thunderbird do that and therefore
don't "Require: sendmail".

> > 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.

Isn't that what escalating the version number to a higher layer (ie. RPM
and yum) is all about? Currently, a break in ABI would result in an
executable loader error. It would just be a conscious effort to move
catching it from there to package management. If dlsym(3) were more
verbose, it might even expose changes API/ABI changes.

At any rate, other packages do it. Some multimedia apps do. Apache httpd
does it. For apache, module (or plugin or whatever they call it)
packages can be added or removed without affecting the system much.

It's a huge effort, I know, but all I'm asking is if it's not in the
guiding principles list that Fedora has. It would certainly make
packagers and spinners very happy.
--

Richi Plana