[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug in Gnuastro's multiple shared libraries

Thanks a lot Sergio,
I'll implement these as soon as I have some free time and be sure to check this (and other) Lintian warnings more carefully :-). 

Thanks again :-),
Mohammad

On 10/4/23 09:33, Sergio Gelato wrote:

According to https://udd.debian.org/lintian/?email1=&email2=&email3=&packages=gnuastro&ignpackages=&format=html&lt_error=on&lt_warning=on&lt_information=on&lintian_tag=#all lintian does emit a "link-to-shared-library-in-wrong-package" for this at severity "warning".

An alternative to Breaks:, if you want the new libgnuastro-dev to be coinstallable with libgnuastro17 without having to push an update to the latter, may be to use dpkg-divert.
________________________________________
From: Mohammad Akhlaghi <mohammad@akhlaghi.org>
Sent: Wednesday, 4 October 2023 01:42
To: Sergio Gelato; debian-astro@lists.debian.org
Subject: Re: Bug in Gnuastro's multiple shared libraries

Hi Sergio,

Thanks a lot!

Until now, I was expecting that Lintian would find such issues. Is there
any other test to do after the trial packaging that can catch such mistakes?

Thanks again,
Mohammad

On 10/3/23 12:27, Sergio Gelato wrote:

I think you just need to add a line to debian/libgnuastro-dev.install to move the .so link to that package. Or change the third line to read usr/lib/*/*.so .

Then the libgnuastro-dev package needs a Breaks: on older versions of libgnuastro1* where libgnuastro_make.so is in the library package.

As always, consult the policy manual when in doubt.
________________________________________
From: Mohammad Akhlaghi <mohammad@akhlaghi.org>
Sent: Tuesday, 3 October 2023 11:33
To: debian-astro@lists.debian.org
Subject: Re: Bug in Gnuastro's multiple shared libraries

Hi Thorsten,

Thanks a lot for the great explanation, I understand the problem much
better now now :-)!

Within Gnuastro's installed library, the 'libgnuastro_make.so' file is
just a symbolic link to 'libgnuastro_make.so.18.0.0'. The same way that
'libgnuastro.so' is a symbolic link to 'libgnuastro.so.18.0.0'.

In the P.S. you can see the installed Gnuastro library files (it is also
attached in case the email viewer makes it hard to read).

Probably the reason that the Debian packaging is treating 'libgnuastro'
differently from 'libgnuastro_make' is that the latter is not an
independent package. Does this sound reasonable?

As I think more about it, the GNU Make extensions of Gnuastro are indeed
used in other contexts from the low-level library (it has a different
purpose). So I think it is good to separate it in any case ;-).

Thanks again :-),
Cheers,
Mohammad

P.S.

$ ls -l /usr/local/lib/libgnuastro*
-rw-r--r-- 1 root root 6772824 Sep 22 19:48 /usr/local/lib/libgnuastro.a
-rwxr-xr-x 1 root root    1160 Sep 22 19:48 /usr/local/lib/libgnuastro.la
-rw-r--r-- 1 root root    5992 Sep 22 19:48
/usr/local/lib/libgnuastro_make.a
-rwxr-xr-x 1 root root    1225 Sep 22 19:48
/usr/local/lib/libgnuastro_make.la
lrwxrwxrwx 1 root root      26 Jun  9 19:53
/usr/local/lib/libgnuastro_make.so.18 -> libgnuastro_make.so.18.0.0
lrwxrwxrwx 1 root root      26 Sep 22 19:48
/usr/local/lib/libgnuastro_make.so -> libgnuastro_make.so.18.0.0
-rwxr-xr-x 1 root root   16152 Jun  9 19:53
/usr/local/lib/libgnuastro_make.so.18.0.0
lrwxrwxrwx 1 root root      21 Jun  9 19:53
/usr/local/lib/libgnuastro.so.18 -> libgnuastro.so.18.0.0
-rwxr-xr-x 1 root root 5236384 Jun  9 19:53
/usr/local/lib/libgnuastro.so.18.0.0
lrwxrwxrwx 1 root root      21 Sep 22 19:48
/usr/local/lib/libgnuastro.so -> libgnuastro.so.18.0.0





On 10/3/23 10:34, Thorsten Alteholz wrote:

Hi Mohammad,

there is package libgnuastro18 which contains
/usr/lib/x86_64-linux-gnu/libgnuastro_make.so and libgnuastro17 which
contains the same file.
As these are shared libraries, they need to be installable at the same
time (broadly speaking), which is not possible due to this file
conflict. I assume that libgnuastro_make.so is different in both versions.

So adding libgnuastro_make.so to a separate package  would not help
(libgnuastro17 would not work with the libgnuastro_make.so from
libgnuastro18). You need to introduce a versioned libgnuastro_make (and
put the libgnuastro_make.so as a link into the corresponding -dev package).
As there is no versioned libgnuastro_make.so in libgnuastro17 and you
can not change this, you need to change the name of libgnuastro_make.so
in libgnuastro18 to avoid to introduce Conflicts: between the -dev
package and libgnuastro17.

I hope this makes sense to you

Good luck with your data release

     Thorsten
Reply to: