Your message dated Fri, 22 Jan 2010 15:24:47 +0100
with message-id <20100122142447.gd23...@rivendell>
and subject line Re: Bug#566249: Missing support for broken "SONAME libfoo.so"
has caused the Debian Bug report #566249,
regarding Missing support for broken "SONAME libfoo.so"
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.)
--
566249: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566249
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.15.4.1
Severity: normal
File: /usr/bin/dpkg-shlibdeps
Hi,
in the process of packaging the Intel pro c/c++ compiler I run into
the problem that their libraries have broken "SONAME libfoo.so". They
do not have any soversion at all. Because of this dpkg-shlibdeps
ignores those libraries completly and one can not create a shlibs
entry for them.
I think it would be better if a soversion of 0 would be assumed in
such cases so that one can still get automatic dependencies for such
libs. The change in dpkg-shlibdeps would be simple:
sub split_soname {
my $soname = shift;
if ($soname =~ /^(.*)\.so\.(.*)$/) {
return wantarray ? ($1, $2) : 1;
} elsif ($soname =~ /^(.*)-(\d.*)\.so$/) {
return wantarray ? ($1, $2) : 1;
+ } elsif ($soname =~ /^(.*)\.so$/) {
+ return wantarray ? ($1, 0) : 1;
} else {
return wantarray ? () : 0;
}
}
If that is acceptable then please do clone the bug to dh_makeshlibs so
it automatically generates dependencies for such libs as well.
MfG
Goswin
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable-i386
APT policy: (1001, 'unstable-i386'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29.4-frosties-2 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg-dev depends on:
ii binutils 2.19.51.20090805-1 The GNU assembler, linker and bina
ii bzip2 1.0.5-3 high-quality block-sorting file co
ii dpkg 1.15.4.1 Debian package management system
ii libtimedate-perl 1.1600-9 Time and date functions for Perl
ii lzma 4.43-14 Compression method of 7z format in
ii make 3.81-6 An utility for Directing compilati
ii patch 2.5.9-5 Apply a diff file to an original
ii perl [perl5] 5.10.0-24 Larry Wall's Practical Extraction
ii perl-modules 5.10.0-24 Core Perl modules
Versions of packages dpkg-dev recommends:
ii build-essential 11.4 Informational list of build-essent
ii fakeroot 1.12.5 Gives a fake root environment
ii gcc [c-compiler] 4:4.3.3-9 The GNU C compiler
ii gcc-4.3 [c-compiler] 4.3.4-1 The GNU C compiler
ii gcc-4.4 [c-compiler] 4.4.1-1 The GNU C compiler
ii gnupg 1.4.9-4 GNU privacy guard - a free PGP rep
ii gpgv 1.4.9-4 GNU privacy guard - signature veri
Versions of packages dpkg-dev suggests:
ii debian-keyring 2009.05.28 GnuPG (and obsolete PGP) keys of D
ii debian-maintainers 1.64 GPG keys of Debian maintainers
-- no debconf information
--- End Message ---
--- Begin Message ---
On Fri, 22 Jan 2010, Goswin von Brederlow wrote:
> in the process of packaging the Intel pro c/c++ compiler I run into
> the problem that their libraries have broken "SONAME libfoo.so". They
> do not have any soversion at all. Because of this dpkg-shlibdeps
> ignores those libraries completly and one can not create a shlibs
> entry for them.
>
> I think it would be better if a soversion of 0 would be assumed in
> such cases so that one can still get automatic dependencies for such
> libs.
Huh, no. This assumption is not safe IMO (if upstream ever decides to
be sane, it will probably start at 0 and you don't want to mix up
both the version 0 and the unversionned one). It's a known limitation of
shlibs, you will have to cope with it.
I would suggest to use symbols files instead, they can deal with
unversioned libraries since they encode the full SONAME.
Cheers,
--
Raphaël Hertzog
--- End Message ---
