<div dir="ltr"><div dir="ltr"><div>Hey Thomas,</div><div><br></div><div>Thanks for the quick answer (you may even be too fast for me :)).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 5, 2022 at 4:37 PM Thomas Schmitt <<a href="mailto:scdbackup@gmx.net">scdbackup@gmx.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
do i get it right that the format is specified by<br>
<a href="https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps" rel="noreferrer" target="_blank">https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps</a><br>
?<br>
<br>
If so, then the goal of having the file<br>
<br>
"In many cases, the dependency generated is too strict as the<br>
application doesn't necessarily use the newly-added symbols which<br>
justify the dependency bump in the shlibs file."<br>
<br>
collides with the upstream version check of libisoburn towards libisofs.<br>
libisoburn will not work with a libisofs version that is older than<br>
seen at compile time.<br>
The minimum version at compile time is defined in libisoburn.h (i.e.<br>
part of the API):<br>
<br>
/** The minimum version of libisofs to be used with this version of libisoburn<br>
at compile time.<br>
@since 0.1.0<br>
*/<br>
#define isoburn_libisofs_req_major 1<br>
#define isoburn_libisofs_req_minor 5<br>
#define isoburn_libisofs_req_micro 4<br>
<br>
So if the Debian packaging software decides on its own that libisofs-1.5.2<br>
is enough at package build time, then compilation will fail.<br></blockquote><div><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the package manager decides that libisofs-1.5.2 is good enough at<br>
run time, then the start-up of libisoburn will fail.<br>
Both failures are intentional and make function isoburn_initialize()<br>
as ugly as paranoid.<br>
<a href="https://sources.debian.org/src/libisoburn/1.5.4-2/libisoburn/burn_wrap.c/#L74" rel="noreferrer" target="_blank">https://sources.debian.org/src/libisoburn/1.5.4-2/libisoburn/burn_wrap.c/#L74</a><br>
<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In general i don't think it is worthwhile to offer old versions of<br>
libisofs to programs which get installed on a system where a newer<br>
version is available.<br>
<br></blockquote><div><br></div><div>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.<br></div></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-------------------------------------------------------------------------<br>
<br>
The .symbols file looks like maintainance effort, if it shall express<br>
more than the existing .ver file (i.e. the list of ABI symbols of<br>
the current version).<br></blockquote><div><br></div><div>And given that it is additional maintenance, I'd agree with you that it may not be necessary.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Google is not overly helpful with search test ".symbols".<br>
Is that file format specific to Debian and its derivatives or does it<br>
play a role in more generic build facilities ?<br>
<br></blockquote><div><br></div><div>I can't really say, let's wait for the package maintainer on this.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The API description in libisofs.h contains information about the version<br>
where a symbol appeared first (IIRC starting with 0.6.2 of 2008). So it<br>
would be possible to create a more differenciated .symbols file than<br>
attributing any symbol to version 1.5.4.<br>
<br>
But if it is only to tell the Debian package build software that really,<br>
really 1.5.4 is the version to use, then i'd propose to generate the<br>
.symbols file freshly in the course of package generation.<br>
<br>
(Bystanding DDs please tell me where in ./debian this can be done.<br>
I would use a shell script that creates .symbols from .ver.<br>
In this case it would be nice if that script could learn the upstream<br>
version automatically, so that it has not to be changed with each version.<br>
Of course, some dh_ magic would be welcome too.)<br>
<br>
<br>
Have a nice day :)<br>
<br>
Thomas<br>
<br>
</blockquote></div></div>