[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: proposed reduction in graphviz dependencies
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
>> 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
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
> 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
Main Index |
Thread Index |