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

[Alexandre Ghiti]

Hey Thomas,

Thanks for the quick answer (you may even be too fast for me :)).

On Tue, Jul 5, 2022 at 4:37 PM Thomas Schmitt <scdbackup at gmx.net> wrote:

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

In an ideal world, the symbols should be backward compatible and then the
'symbols' mechanism should be enough: I'm curious, why would it be
different here?


> 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.
>
>
Ok I see, and in addition, the 3 libraries (libburn, libisofs, libisoburn)
belong to the same project so that would be weird if they are not updated
at the same time.


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

And given that it is additional maintenance, I'd agree with you that it may
not be necessary.


>
> 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 ?
>
>
I can't really say, let's wait for the package maintainer on this.


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-libburnia-devel/attachments/20220711/3f2745d1/attachment.htm>