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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
