On Wednesday 28 March 2012, Sam Roberts wrote:
> 2012/3/24 Stefanos Harhalakis <v13@...>:
> > These are the symbol changes from dpkg-gensymbols:
> > + libnet_pblock_record_ip_offset@... 1.1.6-1
> This was present in 1.1.4, removed in 1.1.5, but then I added it back
> in because our local dpackaging was complaining... Its a null-op, the
> info it updates is no longer present, its only for binary
> compatibility with 1.1.4.
I have already packaged 1.1.5 and I didn't notice any binary incompatibility
issues. There were some symbols that were removed but they were clearly marked
as internal in their documentation:
* Checksums are a real pain in the <beep>!!!
* Function updates referer used to compute the checksum. All
* pblock need to know where is their referer (ie IP header).
* So, this function is called each time a new IP header is inserted.
* It updates the ip_offset field (referer) of each previous pblock.
libnet_pblock_record_ip_offset(libnet_t *l, libnet_pblock_t *p);
As such I suggest you go on and remove that.
> How important is binary compatibility, do you think? Can I break it
> for good reason, or does it just cause pain for the distros?
It is very important to keep binary compatible libraries with the same
version/soname. If you haven't done yet, have a look at the versioning
documentation of libtool. Especially the 'Updating library version
information'. This can be found in the info page or here:
As long as you follow these rules you can break ABI as frequently as you like
since it will be possible to have more than one versions installed on the
system and thus both old and new programs will be able to coexist and function
However, it is not a very good thing to frequently remove public interfaces
(e.g. public function, globally accessibly variables, etc) as it will break
source code compatibility and will require changes from other programs as
well. In general, it's a good practice to keep public interfaces as steady as
The above only refer to public interfaces. There is no reason not to
change/remove/add internal functions.
> I'm having a problem with isic. It calls an internal function to
> calculate checksums that isn't safe - it doesn't receive the buffer
> size, so it has no idea if its overrunning it or not. It was the core
> cause of the array bounds errors. Unfortunately, isic now triggers
> buffer overruns. I'm not too sure what to do, there's a few options:
> 1 - I patched our copy of isic to use the new function that has bounds
> checking, this is the best approach. Not to sure who the patches
> should go to, though. I can even remove the function its calling (its
> severely deprecated), this would perhaps trigger libnet users to
> update their code.
Why not contact Shu Xiao and Mike Frantzen? They are listed as the copyright
holders of isic. In the mean time, if isic is packaged for any distribution
you can always sent your patch to the maintainer to have it applied as part of
the packaging process until it is committed upstream.
> 3 - ... any others? Maybe mark libnet as no longer binary compatible,
> and have isic depend on an older version? suggestions?
You can add a switch to the configure step (e.g. --enable-broken or --enable-
deprecated) that defines a #define and then wrap that code inside that
#define. This way it will be possible for old tools to still be compiled
against a custom compilation of libnet.
Something like this:
[Enable broken functionality]),
if test $enable_broken = yes ; then
AC_DEFINE([BROKEN],, [Enable broken functionality])
AC_MSG_NOTICE([Broken interfaces are enabled. This will go away in
version 1.2.0. See the documentation for more information.])
This will add a new entry in include/config.h like this:
/* Enable broken functionality */
#define BROKEN 1
as long as it is configured with --enable-broken
Then wrap the old code in:
and you're quite fine.
> I'll release by early next week at the latest. I'd like to do it today
> or tomorrow.
Good. Then there's no sense in pushing 1.1.5 to Debian.