Hi Sebastian, Today Sebastian Harl wrote:
> Hi David, > > On Sat, Jun 27, 2009 at 11:36:03PM -0700, da...@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 t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers