[collectd] Bug#535786: Change severity of 535786 to important

[Rodrigo Campos]

On Mon, Aug 31, 2009 at 03:36:28PM +0200, Sebastian Harl wrote:
> Hi,
> 
> On Mon, Aug 31, 2009 at 09:22:49AM -0300, Rodrigo Campos wrote:
> > On Mon, Aug 31, 2009 at 12:34:01PM +0200, Sebastian Harl wrote:
> > > The problem is an error in the build system. collectd ships its own
> > > version of libiptc (which is used by the iptables plugin) because this
> > > library used to be available as a static lib only (which cannot be
> > > linked into a shared object on most architectures). Starting with
> > > version 1.4.3, iptables ships a shared library as well - however, with a
> > > slightly modified API / ABI. Now, the problem is that the build system
> > 
> > It seems it should not change the ABI:
> > 
> > http://markmail.org/message/aqommixeonl5l5sj#query:netfilter%20libiptc+page:1+mid:fdxs37gp6e2igpto+state:results
> > 
> > Patrick said that in the second email of the thread.
> 
> In that thread you pointed out, I could only find patches for the build
> system to basically change 'noinst_LTLIBARIES' to 'lib_LTLIBRARIES' for
> libiptc (i.e. install that library on 'make install' instead of making
> it available for internal use only). Which patch did you have in mind?

And that didn't do the trick ? Now it is installed again and you could use it.
And you can also link to a particular version, so this does not happen again ?



> Well, in Debian we won't need a copy of libiptc any longer but, being an
> upstream developer as well, I think it still makes sense to ship the lib
> in the upstream tarball since the shared libiptc is available for a
> fairly short time only so far.

Sounds ok. But you can simply put into the sources the last library, so you
don't need to support both APIs, you just check if the version (if I'm not wrong,
it have a version now also) available of libiptc is the same or "compatible"
with the one in the sources. If its not, you use the one inside collectd and
you dont link dinamically to that library, just include the ".a". If it is, you
could use the .so

But you would have to make collectd depend/recommend/something to that specific
libiptc version if I'm not wrong. I don't know how the libiptc version is
handled since it comes in the iptables package and I don't know if there is any
relation with the libiptc's version and iptables's version. But if its not there
a way to do this, probably upstream would give an answer, since it seems they
want to support the use of libiptc (or at least it seems that in the thread I
paste :)




Thanks,
Rodrigo