Re: librrd4 dependancies

[Sebastian Harl]

Hi David,

On Sat, Jun 27, 2009 at 11:36:03PM -0700, david@... 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].

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

--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin



_______________________________________________
rrd-developers mailing list
rrd-developers@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

[Tobias Oetiker-3]

Hi Sebastian,

Today Sebastian Harl wrote:

> Hi David,
>
> On Sat, Jun 27, 2009 at 11:36:03PM -0700, david@... 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@... ++41 62 775 9902 / sb: -9900

_______________________________________________
rrd-developers mailing list
rrd-developers@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

[Sebastian Harl]

Hi Tobi,

On Mon, Jun 29, 2009 at 01:58:08PM +0200, Tobias Oetiker wrote:

> Today Sebastian Harl wrote:
> > 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.

I was thinking about that as well but I see a couple of problems and
(rather minor) disadvantages when using that approach:

 * People using the static library would still need to change their
   build system because static libs do not have a NEEDED entry [1], i.e.
   they cannot specify any dependencies. I'm unsure if that change thus
   should still be considered to be an ABI breakage.

 * I'm also unsure if that's going to work on all platforms even in the
   case of shared objects. If I recall correctly (and I'm quite
   uncertain if I do), some operating systems / dynamic loaders do not
   support recursive loading of shared objects [2] and instead require
   the application to link against all dependencies of some library as
   well. Anybody on this list who has a more in-depth insight into this?

 * By using my approach, applications not using rrd_graph*() (which, I
   suppose, is the more common case) would automatically drop their
   dependency on cairo and pango without requiring any manual changes
   (in Debian those packages would simply be rebuilt).

 * Imho, graphing has nothing to do with round robin databases by
   itself. Even though it's probably one of the main reasons for people
   using RRDtool, I'd call it an "add-on". So separating that into some
   librrd-graph would imho be the "semantical" better choice. This is
   mostly a matter of personal preference though.

Comments?

Cheers,
Sebastian

[1] In case of ELF binaries. I don't know how that field is called in
    other binary formats or whether it exists at all in all binary
    formats.

[2] Which, e.g., would be the case if there's nothing like NEEDED.

--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin



_______________________________________________
rrd-developers mailing list
rrd-developers@...
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers