> [EMAIL PROTECTED]:/cosas/deb]$ dpkg -i oggasm_1.4.0.deb
> Seleccionando el paquete oggasm previamente no seleccionado.
> (Leyendo la base de datos ...
> 78123 ficheros y directorios instalados actualmente.)
> Desempaquetando oggasm (de oggasm_1.4.0.deb) ...
> dpkg: problemas de dependencias impiden la configuración de oggasm:
> oggasm depende de mpg321; sin embargo:
> el paquete mpg321 no está instalado.
> oggasm depende de libmp3-info-perl; sin embargo:
> el paquete libmp3-info-perl no está instalado.
> dpkg: error al procesar oggasm (--install):
> problemas de dependencias - se deja sin configurar
> Se encontraron errores al procesar:
> oggasm
> [EMAIL PROTECTED]:/cosas/deb]$ ll /usr/bin/oggasm
> -rwxr-xr-x 1 root root 14K 2002-02-18 06:24 >
/usr/bin/oggasm
> [EMAIL PROTECTED]:/cosas/deb]$ ls /usr/share/doc/oggasm/
> changelog.Debian.gz copyright README.Debian
Hay un problema interpretativo en su ejemplo, si bien es cierto el
paquete ha sido descomprimido y puesto en su equipo, eso no indica una
clara instalación del mismo, dpkg tiene varias etapas en la instalación
de un paquete y todas ellas son importantes en la instalación del mismo,
el caso es que en debian se considera que un paquete ha sido instalado
por completo cuando este ha sido configurado para su uso, algo que no se
ha concluido en su ejemplo.
Adicionalmente dpkg ha sido programado de forma tal que permite
completar las dependencias posteriormente (aclarando, no instala por
instalar, sino supone que, si instalamos un paquete para su uso y este
depende de otro, entonces tendremos que instalar ese otro paquete, por
tanto dpkg queda a la espera del paquete que satisfaga la dependencia)
si se va instalar el paquete B el cual depende del paquete A, dpkg esta
programado lo suficientemente bien como para descomprimirlo y dejarlo a
espera de la configuración (es el caso de su ejemplo) quedando a la
espera de la instalación del paquete o paquetes que satisfagan dicha
dependencia, pero ello no indica que dpkg instale las cosas por instalar.
Si pensamos un poco como es que apt u otros front-ends de dpkg como
dselect trabajan las dependencias, pues todos ellos harán uso de las
dependencias marcadas al crear el paquete y para ello usan dpkg, para
obtener las dependencias, que faciliten el trabajo es cierto, pero no
por ello se puede catalogar o subestimar el poder de dpkg.
Vayamos un poco mas allá, si fuera cierto lo que usted indica y que dpkg
instala por instalar, entonces uno podría instalar una versión de glibc
de woody en sarge y malograr el sistema, algo que no ocurre, el
siguiente ejemplo es bien sugerente:
sachaca:/home/nmag/Downloads# dpkg --install libc6_2.2.5-11.5_i386.deb
dpkg - warning: downgrading libc6 from 2.3.2.ds1-12 to 2.2.5-11.5.
(Reading database ... 116541 files and directories currently installed.)
Preparing to replace libc6 2.3.2.ds1-12 (using
libc6_2.2.5-11.5_i386.deb) ...
Unpacking replacement libc6 ...
dpkg: error processing libc6_2.2.5-11.5_i386.deb (--install):
trying to overwrite `/lib/libdb1-2.2.5.so', which is also in package
libdb1-compat
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
libc6_2.2.5-11.5_i386.deb
El ejemplo es bien sugerente, no instala, ni siquiera desempaqueta, el
resultado es que el sistema no ha sido tocado siquiera:
sachaca:/home/nmag/Downloads# dpkg --list | grep libc6
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries and Timezone
Ahora si bien es cierto no figura un problema claro de dependencias, por
que dpkg no lo hace claro, y es que las dependencias no sólo se miran de
paquetes que faltan sino de los paquetes que salen y también del
contenido de los mismos, es claro que hay una tubería rota por que de
instalarse se sobreescribirá un archivo de otro paquete.
Y si tratamos de desinstalar ese otro paquete obtenemos:
sachaca:/home/nmag/Downloads# dpkg --purge libdb1-compat
dpkg: dependency problems prevent removal of libdb1-compat:
libc6 depends on libdb1-compat.
dpkg: error processing libdb1-compat (--purge):
dependency problems - not removing
Errors were encountered while processing:
libdb1-compat
De igual forma como evita la instalación también evita la eliminación de
un paquete si este es una dependencia de algún otro paquete.
El sistema de dependencias, además de la consistencia de los mismos y la
estabilidad está completamente garantizada con dpkg que en muchos casos
de la impresión que no es así como en su ejemplo, eso es otra cosa, ya
que como lo expliqué dpkg queda a la espera de la instalación del
paquete que satisfaga la dependencia, de igual forma si un paquete es
dependencia de otro no será eliminado y si un paquete al ser instalado
crea una inconsistencia tampoco será instalado.
Adicionalmente, dpkg salva muchos problemas que a veces son pasados por
alto por el mismo apt. Como anécdota me ha pasado cuando he hecho
upgrades de potato a woody y de woody a sarge, en los cuales apt había
considerado que todo ok, y empezaba la descarga de archivos luego
empezaba el desempaque de los paquetes y en esa etapa saltaba un error
de dpkg (broken pipe) que impedía la descompresión y puesta del
contenido de un paquete a causa de una inconsistencia grabe ocasionada
por otro paquete que había sido instalado y que no formaba parte de la
distro debian, y a fin de no dejar desamparado a dicho paquete "foráneo"
es que dpkg (quien gobierna a apt) detenía todo el proceso, y claro la
solución era sencilla, se desinstalaba el paquete foráneo (manualmente
con dpkg y las dependencias si así lo requiriese dpkg) y luego se
continua la instalación con la opción -f de apt.
Saludos!
nmag only
P.D. Al menos esas capacidades no las he visto en otros sistemas de
paquetes que usan apt pero que no sean los de debian o en ditros basadas
en debian. Las distribuciones que usan apt bajo otros sistemas de
paquetes como rpm -y si que he probado-, hacen del que el apt sea
cochinin, al menos si he visto que genera inconsistencias bien feas sin
que el usuario sepa siquiera que ocurrieron solo hasta que el sistema
fue roto. Al menos eso nunca me ha pasado en debian mientras no forzara
las cosas.
