[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [rant] Too many dependencies
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
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Main Index |
Thread Index |