Subject: found also with libm4ri

From: Cédric Boutillier <[email-masked]>
Date: Mon, 7 Jan 2013 14:02:36 +0100

Hi!

I wanted to mention that when preparing a new version of libm4ri, I also
hit this bug: lintian outputs

W: libm4ri-0.0.20120613: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libm4ri-0.0.20120613.so usr/lib/x86_64-linux-gnu/libm4ri-0.0.20120613.so

whereas the -dev package has (as it should according to [1]) a symlink:
./usr/lib/x86_64-linux-gnu/libm4ri.so -> libm4ri-0.0.20120613.so

[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#devpkg, Section 4.4

Changing the regexp according to the patch by adding a '+' fixes the issue.

Cheers,

Cédric

---

From: Niels Thykier <[email-masked]>
Date: Mon, 07 Jan 2013 16:32:28 +0100

> Changing the regexp according to the patch by adding a '+' fixes the issue.

Hi Cédric,

This missing "+" in the regex has been fixed in Lintian 2.5.11
(experimental)[1]; though my question remains if we should really
re-order those regexes.

~Niels

[1] http://lintian.debian.org/source/libm4ri does not list the the tag,
so I believe it covers your particular package.

---

From: Leo 'costela' Antunes <[email-masked]>
Date: Sun, 19 May 2013 02:22:48 +0200

Hi,

> (experimental)[1]; though my question remains if we should really

I believe you are right. The idea is to find a link with either of the
two formats:
libwhatever.so -> libwhatever-X.so
libwhatever.so -> libwhatever.so.X

So the two regexes really should be mutually exclusive.

However, our package (libevent) actually does the following:
libevent.so -> libevent-2.0.so.2.0.21

My question is: is this worth inclusion in lintian as an acceptable
format, or should I just add an override and be done with it?
FWIW, after a cursory look at the list of tagged packages, there are at
least a couple of other libs using the same format (libdirectfb,
libnet6, probably others).

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]

---

From: Bill Allombert <[email-masked]>
Date: Sat, 21 Sep 2013 00:46:06 +0200

> So the two regexes really should be mutually exclusive.

No. there is no requirement either technical or in policy, for a shared library
to follow any of theses convention and lintian must not assume so.

The only requirement is that for each libraries in the lib package there is at
least one matching symlink lib*.so pointing to it in the -dev package.  The
exact name is a matter of C API that lintian cannot guess.

For example, it is perfectly valid to have
libwhatever.so -> libwhatever-X.so.Y.Z
or even 
libfoo.so -> libbar-X.so.Z
(For example if libbar is an alternative implementation of libfoo, with the same API
but a different ABI. Makefile using gcc -lfoo should still work when libbar-dev is 
installed).

This might explain the large number of false positive for a test which is
marked "certain". This is a regression from previous lintian version.

So I think using a regexp is misguided. It would be more reliable to follow the
symlink.

Cheers,
-- 
Bill. <[email-masked]>

Imagine a large red swirl here.

---

From: Niels Thykier <[email-masked]>
Date: Mon, 23 Sep 2013 16:26:28 +0200

Hi,

> but a different ABI. Makefile using gcc -lfoo should still work when libbar-dev is 

Thanks for clarifying this point, seems like Lintian is wrong here.  To
be honest, I am actually quite happy someone with knowledge in this area
steps up and explains how it is intended/required to work.  This is one
of the many code snippets that have been carried on in the Lintian code
base with no obvious reference to why it works that particular way.

> So I think using a regexp is misguided. It would be more reliable to follow the

The git history (which takes us back to 2004) shows that we have been
using the regex-approach for the past 9 years[1].  snapshot.d.o go as
far back as 0.9.3 (27 Oct 1998) and that version has the same regex as
the code had in 2004.  So this "regression" must be at least 15 years
old now. :)

The tag itself is listed in the mail from 25 Jan 1998, where Christian
Schwarz announced Lintian[2].

"""
The shared library check script detects the following policy violations:

#   [...]
#
# (a foo-dev package should contain a symlink foo.so -> foo.so.0)
#   E: dev-pkg-without-shlib-symlink
#      (==> check does not work correctly yet, [...])
"""

If you happen to still have that old a version of Lintian I'd would
seriously like a copy of it.  Heck, I will even buy you a
beer/$beverage_of_choice if you have that copy and the code indeed did
(or rather, tried to do) the "right thing" back then.  But honestly, I
think there is no regression here; just a regular bug since the
conception of Lintian.

~Niels

[1]
http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob;f=checks/shared-libs;h=c2f35a06712ef4b84101699cdfd0d08baaa1e2eb;hb=020888bca1e21cf8e98934fea04d9352244c97e9#l185

[2] https://lists.debian.org/debian-devel/1998/01/msg01503.html

---

From: Bill Allombert <[email-masked]>
Date: Mon, 23 Sep 2013 20:15:59 +0200

> the code had in 2004.  So this "regression" must be at least 15 years

I did not meant to say that using a regexp was a regression, but that
this bugreport was about a regression :)

Doing a bisection I find the first version to report a false positive for 
the pari package is lintian 2.5.7.

Indeed, the changelog says:

  * checks/shared-libs:
    + [NT] Fix false positive "dev-pkg-without-shlib-symlink"
      for shared libraries using "libtool -release X.Y".
      Thanks to Sven Joachim for the report.  (Closes: #673109)
    + [NT] Fix false positive "dev-pkg-without-shlib-symlink"
      for shared libraries installed in /lib.  Lintian now
      correctly expects the dev-symlink beneath /usr/lib.
      Thanks to Guillem Jover for the report.

So certainly the test was changed.

One other example of false positive I found is that lintian does not allow 
usr/lib/libfoo.so -> usr/lib/x86_64-linux-gnu/libfoo.so.X.Y.Z
which happens in multiarch transition.

Cheers,
Bill.