Re: [rant] Too many dependencies

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Tue, 21 Jul 2009 11:04:18 -0400
Greg Troxel <gdt%ir.bbn.com@localhost> wrote:

> 
> Thomas Klausner <wiz%NetBSD.org@localhost> writes:
> 
> > On Tue, Jul 21, 2009 at 07:00:42AM -0400, Greg Troxel wrote:
> >> The big bug here is librsvg depending on libgsf depending on
> >> gnome.  A file format library should not drag in a desktop
> >> environment.  But if it reallydoes depend on all that, then maybe
> >> the rsvg option to graphviz should be taken out of the default.
> >
> > librsvg depends on libgsf for svgz (compressed svg) support.
> > libgsf depends on gnome-vfs (needs GConf and hal) and GConf.
> > That's not the whole desktop environment :)
> 
> True, but it's part of a desktop environment, and those packages have
> nothing to do with dealing with a file format.
> 
> > We could make svgz support a default-on option for librsvg to trim
> > down the tree for those who prefer less dependencies...
> 
> pkgsrc is encoding the judgement of the maintainers as to what is
> appropriate.  I don't know how prevalent svgz files actually are, and
> whether any significant number of graphviz users want this at all.  My
> own bias is to disable by default bloat-causing options.
> 
> >> In the case of graphviz, I think most of the extension languages
> >> should be off by default, becuase I've never heard of anyone using
> >> them.  That would get rid of ocaml, lua, and tk/tcl.
> >
> > Or make them default-off options or separate packages...
> 
> I mean to remove them from PKG_SUGGESTED_OPTIONS.
> Sure, separate packages would be fine if someone wants to do the work.
> 
The problems are the load on the package maintainer, and the
combinatorial complexity downstream.

First -- if you add a new option for any package, you double the number
of dependencies a conscientious maintainer has to test.  Two options?
That's four different test cases.  Add a third option?  It's now eight
cases of combinations of options.

The second problem is downstream: what options did the developer of
package foo use, when there's a three-level indirect dependency on
package bar which someone else wants to install?  Heck -- I had a
problem, some years ago, where the *presence* of a particular package
caused problems for another package -- either the developer of the
second package didn't use the first one, or installed them in a
different order.  Second -- what options are used for bulk package
compiles?  The defaults?  Are they right?  Does that mean you can't
easily mix and match binaries with home-compiled packages?  You can't
today in some cases, but this will make it worse.

I'm no saying this is the wrong path, but it does have its
disadvantages.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb