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

[Sebastian Harl]

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.

> Now it is installed again and you could use it.

Right. But for that to happen, we'll have to fix the collectd build
system and the iptables plugin first.

> And you can also link to a particular version, so this does not happen again ?

Right - which is the part that has to be fixed :-)

> > 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

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 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 :)

Depending on the right version of iptables is as easy as depending on
the right version of any other library (i.e. that's handled by
debhelper) - but that's really no issue in this case, since the breakage
happens because of that build problem.

Cheers,
Sebastian

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090831/1906e492/attachment.pgp