Your message dated Tue, 6 Nov 2018 16:42:55 +0100 with message-id <[email protected]> and subject line Re: Bug#912939: dpkg-dev: dpkg-shlibdeps should find and emit shared library packages even if it "can't extract name and version", relevant to rust has caused the Debian Bug report #912939, regarding dpkg-dev: dpkg-shlibdeps should find and emit shared library packages even if it "can't extract name and version", relevant to rust to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 912939: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912939 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dpkg-dev Version: 1.19.2 Severity: important Dear Maintainer, Rust shared libraries look like this: $ cat /var/lib/dpkg/info/libstd-rust-1.30\:amd64.shlibs [..] libarena bf854c6df1c65266 libstd-rust-1.30 (>= 1.30.0+dfsg1) [..] libstd 5a15e25ec06d05ec libstd-rust-1.30 (>= 1.30.0+dfsg1) [..] $ ls -1 /usr/lib/x86_64-linux-gnu/*.so [..] /usr/lib/x86_64-linux-gnu/libarena-bf854c6df1c65266.so [..] /usr/lib/x86_64-linux-gnu/libstd-5a15e25ec06d05ec.so [..] dpkg-shlibdeps works for libraries whose hashes start with 0-9 but not a-f: $ mkdir -p debian && touch debian/control # need to satisfy some checks $ cat lol.c int main() {} $ rm -f debian/substvars && gcc lol.c -lstd-5a15e25ec06d05ec && dpkg-shlibdeps a.out 2>/dev/null && cat debian/substvars shlibs:Depends=libc6 (>= 2.2.5), libstd-rust-1.30 (>= 1.30.0+dfsg1) $ rm -f debian/substvars && gcc lol.c -larena-bf854c6df1c65266 && dpkg-shlibdeps a.out 2>/dev/null && cat debian/substvars shlibs:Depends=libc6 (>= 2.2.5) Ideally it should Just Work in both cases. It is perfectly OK for us if the Depends are (= $version) rather than (>= $version) - in fact the former is probably better. X -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev depends on: ii binutils 2.31.1-7 ii bzip2 1.0.6-9 ii libdpkg-perl 1.19.2 ii make 4.2.1-1.2 ii patch 2.7.6-3 ii perl 5.26.2-7+b1 ii tar 1.30+dfsg-2 ii xz-utils 5.2.2-1.3 Versions of packages dpkg-dev recommends: ii build-essential 12.5 ii fakeroot 1.23-1 ii gcc 4:8.2.0-1 ii gcc-7 [c-compiler] 7.3.0-30 ii gcc-8 [c-compiler] 8.2.0-9 ii gnupg 2.2.10-3 ii gnupg2 2.2.10-3 ii gpgv 2.2.10-3 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2018.09.30 -- no debconf information
--- End Message ---
--- Begin Message ---Control: tag -1 wontfix Hi! On Sun, 2018-11-04 at 20:35:37 -0800, Ximin Luo wrote: > Package: dpkg-dev > Version: 1.19.2 > Severity: important > Rust shared libraries look like this: > > $ cat /var/lib/dpkg/info/libstd-rust-1.30\:amd64.shlibs > [..] > libarena bf854c6df1c65266 libstd-rust-1.30 (>= 1.30.0+dfsg1) > [..] > libstd 5a15e25ec06d05ec libstd-rust-1.30 (>= 1.30.0+dfsg1) > [..] > $ ls -1 /usr/lib/x86_64-linux-gnu/*.so > [..] > /usr/lib/x86_64-linux-gnu/libarena-bf854c6df1c65266.so > [..] > /usr/lib/x86_64-linux-gnu/libstd-5a15e25ec06d05ec.so > [..] > > dpkg-shlibdeps works for libraries whose hashes start with 0-9 but not a-f: Yes. As mentioned on IRC this is due to the format used in the .shlibs files, which do not have the explicit SONAME for the shared object. And to be able to match it needs to decompose the filename and then match on the components. It then also has to support both common formats to encode the SONAME, the one used for public libraries: libNAME.so.VERSION and the one for private/internal ones: libNAME-VERSION.so In which case it needs to know where the VERSION starts, as dashes are permitted in the name. So I don't think we can change the regex to accept non-starting digits for VERSION, w/o introducing indeterminism and/or breakage. > Ideally it should Just Work in both cases. > > It is perfectly OK for us if the Depends are (= $version) rather than > (>= $version) - in fact the former is probably better. But, as also mentioned on IRC; you can always remove the .shlibs file and simply use a .symbols file, with a pattern matching all symbols, either a (symver) or a (regex) might do. So, I think we can just close this report. Thanks, Guillem
--- End Message ---
