[rrd-developers] librrd4 dependancies

[Tobias Oetiker]

Hi Sebastian,

Today Sebastian Harl wrote:

> Hi David,
>
> On Sat, Jun 27, 2009 at 11:36:03PM -0700, david at lang.hm wrote:
> > I can see how rrdtool would have depenancies on various graphics
> > libraries (since in most environments it creates graphs), but librrd4
> > only populates the rrd datastores, it doesn't create the graphs so why
> > does it depend on libcairo and libpango?
>
> Unfortunately, this assertion is wrong. librrd bundles _all_ function-
> ality found in RRDtool - including graph creation. In fact, the rrdtool
> binary is only a small wrapper around the library, basically parsing the
> first command line option and then dispatching stuff to the right
> function.
>
> > this is the list of packages that get added on my systems when I add
> > librrd4
> >
> > defoma fontconfig fontconfig-config libcairo2 libdatrie0
> > libdirectfb-1.0-0 libfontconfig1 libfreetype6 libnewt0.52 libpango1.0-0
> > libpango1.0-common libpixman-1-0 libpng12-0 librrd4 libthai-data libthai0
> > libts-0.0-0 libx11-6 libx11-data libxau6 libxcb-render-util0
> > libxcb-render0 libxcb-xlib0 libxcb1 libxdmcp6 libxft2 libxrender1
> > ttf-dejavu ttf-dejavu-core ttf-dejavu-extra whiptail
> >
> > for a desktop this may not matter, but for embeded things or systems
> > with small flash disks (i.e. OLPC and netbooks) these packages do add up
> [...]
>
> I fully agree that splitting the graphing part and other database
> handling would be _very_ nice to have. However, this is an issue that
> has to be discussed and implemented upstream - it's not a "side-effect"
> of the Debian packaging. I've thus Cc'ed the upstream developers mailing
> list, hoping for comments and suggestions.
>
> Imho, the best thing to do would be to separate graphing into it's own
> library, say librrd-graph. Just doing so should require adapting the
> build system only. However, this introduced backward-incompatible
> changes to the API and ABI of librrd, so it would require a major soname
> version bump, so Tobi has to decide about that. I do not expect that
> lots of C programs use rrd_graph*(), so only few other projects should
> be affected by that change and require code (and build system) changes
> [1].

how about having the following structure

librrd - including the graph stuff and puling in the rest from
librrd-base

this means that people who want only the base stuff can link
against librrd-base ... and it would not break existing usage as
linking against librrd would pul in librrd-base automatically.

cheers
tobi


> Cheers,
> Sebastian
>
> [1] The following packages seem to be affected in Debian: lm-sensors-3,
>     ntop, xymon. I was using the following shell snippet to do a quick
>     check (in Debian unstable):
>
>       pkgs=$( ( build-rdeps librrd-dev; build-rdeps librrd2-dev ) \
>           | egrep -v '^(Reverse|Found|-)' | sort -u )
>       for pkg in $pkgs; do
>           apt-get source $pkg; ( cd $pkg-*; egrep -r '\<rrd_graph' . )
>       done
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900