Bug#912939: marked as done (dpkg-dev: dpkg-shlibdeps should find and emit shared library packages even if it "can't extract name and version", relevant to rust)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Bug#912939: marked as done (dpkg-dev: dpkg-shlibdeps should find and emit shared library packages even if it "can't extract name and version", relevant to rust)

Debian Bug Tracking System
Your message dated Tue, 6 Nov 2018 16:42:55 +0100
with message-id <[hidden email]>
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 [hidden email]
immediately.)


--
912939: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912939
Debian Bug Tracking System
Contact [hidden email] with problems

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

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