Re: Bug#56440: lintian: Should check for shlibs that with incorrect package name
Fixing a typo in the cc to debian-policy that caused the original to not
reach there. This discussion is about a lintian check for packages that
provide a shlibs file that lists a dependency on some other package.
Mike Hommey <mh@glandium.org> writes:
> On Mon, Jan 31, 2000 at 04:21:46PM -0500, Joey Hess <joeyh@debian.org> wrote:
>> gsstark@mit.edu wrote:
>>> I can't see any reason a package would list any packages other than
>>> itself in its shlibs file. I suggest putting the check in, and if
>>> there are lots of packages doing this then we can pursue in policy why
>>> and whether it's worthwhile. But I really doubt it's the case.
>> Lots of packages list other packages in their shlibs files. For
>> example, all the xaw replacement libraries must do this.
Are there any of these still in the archive? apt-cache search xaw doesn't
seem to turn up any; all the shlibs files in the libraries shown there
look quite normal.
>> Hm, I just realized something. I belive that policy or the packaging
>> manual currently says that packages that contain libraries should
>> include shlibs files. But why? Wouldn't it make more sense if the
>> shlibs file was in the associated -dev package? After all, the contents
>> of the file only matters if you are doing development with the
>> library. The file format is such they could be moved over wholesale to
>> -dev packages with no changes.
>>
>> Then the proposed lintian check would make sense, though there will
>> still be exceptions.
> 7 years later, I got hit by this in one of my packages. It would have
> helped if lintian gave me at least a warning about the shlibs content...
> Sure there are exceptions, but on my system, there are 17 over 381
> shlibs. As far as it is known to be exceptions, it's not a problem to
> have the warnings there, they could even be put in lintian overrides...
Looking through my system, filtering out dependencies on the same package,
and filtering out comments and udeb lines, I get the following on one
amd64 system:
apt-utils.shlibs:libapt-inst-libc6.3-6 1.1 libapt-inst-libc6.3-6-1.1
gettext-base.shlibs:libasprintf 0 libasprintf0c2
libgamin0.shlibs:libfam 0 libfam0
libsvn-perl.shlibs:libsvn_swig_perl-1 1 libsvn1 (>= 1.4)
nvidia-glx.shlibs:libGL 1 xlibmesa-gl | libgl1
nvidia-glx.shlibs:libGLcore 1 xlibmesa-gl | libgl1
perl-base.shlibs:libperl 5.8 libperl5.8 (>= 5.8.8)
python-subversion.shlibs:libsvn_swig_py-1 1 libsvn1 (>= 1.4)
python2.4-doc.shlibs:libpython2.4 1.0 python2.4 (>= 2.3.90)
totem-xine.shlibs:libtotem-basic plugin libtotem-plparser1 (>= 2.16.1)
totem-xine.shlibs:libtotem-complex plugin libtotem-plparser1 (>= 2.16.1)
totem-xine.shlibs:libtotem-gmp plugin libtotem-plparser1 (>= 2.16.1)
totem-xine.shlibs:libtotem-mully plugin libtotem-plparser1 (>= 2.16.1)
totem-xine.shlibs:libtotem-narrowspace plugin libtotem-plparser1 (>= 2.16.1)
totem-xine.shlibs:libtotem-properties page libtotem-plparser1 (>= 2.16.1)
and this on an i386 system:
apt-utils.shlibs:libapt-inst-libc6.3-6 1.1 libapt-inst-libc6.3-6-1.1
gettext-base.shlibs:libasprintf 0 libasprintf0c2
libc6-i686.shlibs:libanl 1 libc6 (>= 2.5)
libc6-i686.shlibs:libBrokenLocale 1 libc6 (>= 2.5)
libc6-i686.shlibs:libc 6 libc6 (>= 2.5)
libc6-i686.shlibs:libcidn 1 libc6 (>= 2.5)
libc6-i686.shlibs:libcrypt 1 libc6 (>= 2.5)
libc6-i686.shlibs:libdl 2 libc6 (>= 2.5)
libc6-i686.shlibs:libm 6 libc6 (>= 2.5)
libc6-i686.shlibs:libnsl 1 libc6 (>= 2.5)
libc6-i686.shlibs:libnss_compat 2 libc6 (>= 2.5)
libc6-i686.shlibs:libnss_dns 2 libc6 (>= 2.5)
libc6-i686.shlibs:libnss_files 2 libc6 (>= 2.5)
libc6-i686.shlibs:libnss_hesiod 2 libc6 (>= 2.5)
libc6-i686.shlibs:libnss_nis 2 libc6 (>= 2.5)
libc6-i686.shlibs:libnss_nisplus 2 libc6 (>= 2.5)
libc6-i686.shlibs:libpthread 0 libc6 (>= 2.5)
libc6-i686.shlibs:libresolv 2 libc6 (>= 2.5)
libc6-i686.shlibs:librt 1 libc6 (>= 2.5)
libc6-i686.shlibs:libthread_db 1 libc6 (>= 2.5)
libc6-i686.shlibs:libutil 1 libc6 (>= 2.5)
libgamin0.shlibs:libfam 0 libfam0
libsvn-perl.shlibs:libsvn_swig_perl-1 1 libsvn1 (>= 1.4)
libzephyr3-krb.shlibs:libzephyr 3 libzephyr3
nvidia-glx.shlibs:libGL 1 xlibmesa-gl | libgl1
nvidia-glx.shlibs:libGLcore 1 xlibmesa-gl | libgl1
python-subversion.shlibs:libsvn_swig_py-1 1 libsvn1 (>= 1.4)
python2.4-doc.shlibs:libpython2.4 1.0 python2.4 (>= 2.3.90)
I detect a couple of patterns here. First, many of these would be dealt
with by not warning if the package Provides the same package that it
declares a dependency on. This takes care of apt-utils, gettext-base,
libgamin0, and libzephr3.
I think libc6-i686 may have an unnecessary shlibs file. The contents are
identical to the libc6 shlibs file except that the latter also contains
ld-linux, and libc6-i686 pre-depends on libc6, so I don't see any need for
it to also ship a duplicate shlibs file. But even if the glibc
maintainers need this for some reason, we can make it a special case.
totem-xine is a bug. It's including plugins in /usr/lib/totem in its
shlibs file with bizarre SONAMEs. I'm not sure where the bug is, but I
think it's legitimate for lintian to complain about it.
python2.4-doc and perl-base looks like bugs to me. Those package don't
provide the library and therefore shouldn't be providing the shlibs file.
I can't see any harm in just deleting those shlibs files and I think it's
legitimate for lintian to complain about them.
I don't entirely understand what's going on with libsvn-perl and
python-subversion, but those too look like bugs to me. Despite the
libraries being in those packages, they're declaring dependencies on
libsvn1, which doesn't provide the libraries. Another legitimate warning.
This leaves nvidia-glx, which is a bizarre case that I'm quite comfortable
saying needs an override.
So, at least at first glance, it looks to me like a lintian warning is
entirely legitimate provided that it doesn't warn if the package being
checked Provides the package listed in shlibs. If you want to check the
shlibs files on your system, the code I'm using is:
cd /var/lib/dpkg/info
for *.shlibs ; do
grep -vH `echo $f | sed 's/\.shlibs//'` $f | grep -v udeb | grep -v '\#'
done
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: