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

[Rodrigo Campos]

On Mon, Aug 31, 2009 at 09:55:52PM +0200, Sebastian Harl wrote:
> Hi Rodrigo,
> 
> On Mon, Aug 31, 2009 at 04:27:42PM -0300, Rodrigo Campos wrote:
> > On Mon, Aug 31, 2009 at 03:36:28PM +0200, Sebastian Harl wrote:
> > > On Mon, Aug 31, 2009 at 09:22:49AM -0300, Rodrigo Campos wrote:
> > > > 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 ?
> 
> Well, that has nothing to do with API / ABI changes but rather about
> making the library available at all.

Well, but if it is available and ready to be used, that's all you need to fix
it. (if I'm not wrong)

> > 
> > 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
> 
> Hrm … that approach could be used as well. However, imho, if libiptc is
> available in the build system, we should use that version since that's
> more likely in sync with the kernel used on that system (I really don't
> think / hope that this might be a problem but this way we're save).
> 
> I do not expect that supporting both APIs should be a big deal - after
> all the differences should be really small, so being more flexible
> should be easy to implement and thus should be preferred imho.

But you can't prevent future API changes. Perhaps I'm missing somethig, but
well, I would let upstream deal with it ;)




Thanks,
Rodrigo