Bug#687022: found also with libm4ri
On 2013-09-21 00:46, Bill Allombert wrote: On Sun, May 19, 2013 at 02:22:48AM +0200, Leo 'costela' Antunes wrote: Hi, On 07/01/13 16:32, Niels Thykier wrote: 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. 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. Hi, 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). 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. 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, 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687022: found also with libm4ri
On Mon, Sep 23, 2013 at 04:26:28PM +0200, Niels Thykier wrote: 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, 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. :) 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687022: found also with libm4ri
On Sun, May 19, 2013 at 02:22:48AM +0200, Leo 'costela' Antunes wrote: Hi, On 07/01/13 16:32, Niels Thykier wrote: 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. 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. 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. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687022: found also with libm4ri
Hi, On 07/01/13 16:32, Niels Thykier wrote: 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. 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] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687022: found also with libm4ri
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 signature.asc Description: Digital signature
Bug#687022: found also with libm4ri
On 2013-01-07 14:02, Cédric Boutillier wrote: 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 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
