Primeiramente. Às vezes, quando as pessoas falam sobre bibliotecas, elas estão falando sobre pacotes .deb que fornecem bibliotecas para outros pacotes. Nós vamos lidar com esse caso primeiro. O outro contexto em que você ouve o termo biblioteca usada é o sentido tradicional .so objeto compartilhado . Nós vamos lidar com esse segundo.
apt-cache depends <package_name> retornará uma lista de pacotes que são dependências de <package name> . Os pacotes não são necessariamente congruentes com as bibliotecas (ou seja, bibliotecas no sentido de arquivos .so vinculáveis), mas nas bibliotecas Debian e Ubuntu são geralmente empacotados como lib<something> . Se você fizer um dpkg -l |grep <library package name> , poderá descobrir qual pacote contém quais bibliotecas estão instaladas.
kelliott@mis-ke-lnx:~$ apt-cache depends perl
perl
Depends: perl-base
Depends: perl-modules
Depends: libbz2-1.0
Depends: libc6
Depends: libdb4.7
Depends: libgdbm3
Depends: zlib1g
kelliott@mis-ke-lnx:~$ dpkg -l |grep libc6
ii libc6 2.11.2-10 Embedded GNU C Library: Shared libraries
ii libc6-dev 2.11.2-10 Embedded GNU C Library: Development Libraries and Header Files
Ou você pode seguir pelo outro caminho. Se você está se perguntando qual pacote exigiu o pacote libwww-perl , você pode usar este prático script perl para retornar uma lista de libwww-perl de dependências reversas que são também instaladas.
#!/usr/bin/env perl
use strict;
use warnings;
use AptPkg::Cache;
my $cache = AptPkg::Cache->new;
my $pkg = $ARGV[0]
or die 'supply a package name as the first arg';
my @acrd = split /\s+/, 'apt-cache rdepends $pkg';
my $state;
for (@acrd) {
unless ( $_ eq 'Reverse' or $_ eq 'Depends:' ) {
$state = $cache->{$_}->{'CurrentState'};
print "$_\n" if $state eq 'Installed';
}
}
Agora, os arquivos de objeto compartilhado .so são um pouco diferentes. Eu gosto de usar uma combinação de ldd e apt-file . Digamos que eu esteja interessado nos arquivos de objeto vinculados a ls :
kelliott@mis-ke-lnx:~$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff8b05d000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007fcfb7e24000)
librt.so.1 => /lib/librt.so.1 (0x00007fcfb7c1c000)
libacl.so.1 => /lib/libacl.so.1 (0x00007fcfb7a14000)
libc.so.6 => /lib/libc.so.6 (0x00007fcfb76b3000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fcfb74af000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcfb8057000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fcfb7292000)
libattr.so.1 => /lib/libattr.so.1 (0x00007fcfb708e000)
kelliott@mis-ke-lnx:~$ apt-file search libattr.so.1
ia32-libs: /lib32/libattr.so.1
ia32-libs: /lib32/libattr.so.1.1.0
libattr1: /lib/libattr.so.1
libattr1: /lib/libattr.so.1.1.0
kelliott@mis-ke-lnx:~$ dpkg -l |grep libattr1
ii libattr1 1:2.4.44-2 Extended attribute shared library
kelliott@mis-ke-lnx:~$ file /lib/libattr.so.1
/lib/libattr.so.1: symbolic link to 'libattr.so.1.1.0'
kelliott@mis-ke-lnx:~$ file /lib/libattr.so.1.1.0
/lib/libattr.so.1.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
Como você pode ver, nosso bom amigo ls tem algumas bibliotecas ligadas a ele. libattr.so.1 manipula os atributos de arquivo, se bem me lembro. Fazendo um apt-file search contra ele mostra que ele foi instalado por dois pacotes ia32-libs e libattr1 (um para 32 bits e outro para 64 bits). E no meu sistema, parece que o pacote libattr1 (na versão 1: 2.4.44-2) instalou o arquivo de objeto compartilhado libattr.so, que após investigação adicional está na versão 1.1.0.