Re: proposed reduction in graphviz dependencies

[Jens Rehsack <rehsack%googlemail.com@localhost>]

Greg Troxel wrote:
> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:
> 
>> On Wed, Jul 22, 2009 at 10:04:17AM +1000, Sarton O'Brien wrote:
>>> On 22/07/2009 9:57 AM, Joerg Sonnenberger wrote:
>>>> On Tue, Jul 21, 2009 at 07:48:56PM +0900, OBATA Akio wrote:
>>>>> I wonder if we should introduce suggested option set.
>>>>> Say, each packages define PKG_SUGGESTED_OPTIONS.lite,
>>>>> PKG_SUGGESTE_OPTIONS.gnome and so on
>>>>> and user define PKG_SUGGESTED_OPTIONS_SET=lite.
>>>> More pain for maintainance for little gain.  Lovely.
>>> You're the ideas man though, any alternate suggestions? Being a 'user'  
>>> in the purest sense, I have no idea what tips the scales towards pain  
>>> nor gain.
>> Part of the problem starts from your mail. The package options generally
>> fall into two categories.
>>
>> Some are more or less widely supported and generic ("x11"). That's a
>> pretty short list. Making e.g. the librsvg package optionally depend on
>> libgsf as option "gnome" is reasonable. The important part here is:
>> keep the number of wide scale options small or they are not going to help
>> much.
>>
>> The other class are fine-grained options that are relatively package
>> specific. This are things like what database adapter to use in the case
>> of Django or what codecs to support for transcode/mplayer. The core
>> problem here is that selecting a small subset is very likely to make the
>> package unusable by default. If you care, check the options and select
>> what you need.
>>
>> Also keep in mind that every option needs at least some basic testing
>> for every update or it is just going to bitrot. The result are angry
>> complains why something is not working correctly.
> 
> Well said.  What I was trying to get at is
> 
>   for packages with "too many" dependencies, identify options that
>   dramatically reduce the dependency footprint without making the
>   package significantly less useful in the normal case.  Move those out
>   of PKG_SUGGESTED_OPTIONS.
> 
> For graphviz:
> 
> These options are enabled by default:
>         gd gtk lua pangocairo perl rsvg swig tcl x11
> 
> These options are currently enabled:
>         gd gtk lua pangocairo perl rsvg swig x11
> 
> [I have -tcl in PKG_DEFAULT_OPTIONS.]
> 
> I'd drop lua, perl, swig from that.  I have yet to meet anyone who uses
> them.

tcl and perl? At least: me and my current customer - for automatic use of
graphviz features in hosting environment. swig is the base for script
language interfaces.

> I'd drop rsvg as long as that lib pulls in libgsf.

Then graphviz can't read .svg files ...

> I don't know about pangocairo.

Required for rsvg.

> Objections?  Jens - what do you think?

Maybe an -gnome could be recognized as -pangocairo -rsvg (reasonable?).

My point of view for suggested options is: how usable the binary packages
would be, the people use directly instead from build on their own. This
means to me: maximum format readability, some prominent language interfaces.
If you have a better idea how to handle from this point of view, I'm glad to
read proposals.

Best regards,
Jens