[Pkg-libburnia-devel] Bug#1014400: libisofs: Add symbol file

[Thomas Schmitt]

Hi,

do i get it right that the format is specified by
  https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
?

If so, then the goal of having the file

  "In many cases, the dependency generated is too strict as the
   application doesn't necessarily use the newly-added symbols which
   justify the dependency bump in the shlibs file."

collides with the upstream version check of libisoburn towards libisofs.
libisoburn will not work with a libisofs version that is older than
seen at compile time.
The minimum version at compile time is defined in libisoburn.h (i.e.
part of the API):

  /** The minimum version of libisofs to be used with this version of libisoburn
      at compile time.
      @since 0.1.0
  */
  #define isoburn_libisofs_req_major  1
  #define isoburn_libisofs_req_minor  5
  #define isoburn_libisofs_req_micro  4

So if the Debian packaging software decides on its own that libisofs-1.5.2
is enough at package build time, then compilation will fail.
If the package manager decides that libisofs-1.5.2 is good enough at
run time, then the start-up of libisoburn will fail.
Both failures are intentional and make function isoburn_initialize()
as ugly as paranoid.
  https://sources.debian.org/src/libisoburn/1.5.4-2/libisoburn/burn_wrap.c/#L74

In general i don't think it is worthwhile to offer old versions of
libisofs to programs which get installed on a system where a newer
version is available.

-------------------------------------------------------------------------

The .symbols file looks like maintainance effort, if it shall express
more than the existing .ver file (i.e. the list of ABI symbols of
the current version).

Google is not overly helpful with search test ".symbols".
Is that file format specific to Debian and its derivatives or does it
play a role in more generic build facilities ?

The API description in libisofs.h contains information about the version
where a symbol appeared first (IIRC starting with 0.6.2 of 2008). So it
would be possible to create a more differenciated .symbols file than
attributing any symbol to version 1.5.4.

But if it is only to tell the Debian package build software that really,
really 1.5.4 is the version to use, then i'd propose to generate the
.symbols file freshly in the course of package generation.

(Bystanding DDs please tell me where in ./debian this can be done.
I would use a shell script that creates .symbols from .ver.
In this case it would be nice if that script could learn the upstream
version automatically, so that it has not to be changed with each version.
Of course, some dh_ magic would be welcome too.)


Have a nice day :)

Thomas