Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
urpmi mola | 18 comentarios (18 temáticos, editoriales, 0 ocultos)
Pues nada, por partes (none / 0) (#15)
por jorginius ("jorginius" en Google Mail) a las Mon Jul 21st, 2003 at 06:50:55 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

O sea primero lo busco y después lo instalo, dpkg (porque apt-get lo hace automáticamente) te dice "exactamente" que paquete te falta y NO el archivo que después debes buscar, por lo tanto aquí deb es más potente ;-)

Claro: dpkg te dice la dependencia que falta, que da la casualidad que se llama como el paquete.

Pero es que en rpm puedes ver igual las dependencias por los paquetes, así que sigo sin ver porqué dicen que las dependencias del rpm son peores (aún cuando sus dependencias son más flexibles. Pueden colocarse por archivos sueltos y en deb no :-P. O hace más sencillo escribir paquetes equivalentes, sin tener que inventar una dependencia abstracta).

Además, aún suponiendo que las dependencias por paquetes no aparecieran en alguna estúpida distribución: tampoco es apocalíptico adivinar que la dependencia es libglib-1.2.so.0 corresponde al paquete libglib1.2-1.2.10-6mdk.i586.rpm (eso, como ya digo, sin fijarnos en el "libglib1.2 >= xxxx" que no "empieza a utilizar Mandrake", como comentas, sino que que ha estado entre nosotros desde RedHat 4.0 y los albores de rpm).

¿Qué no es suficiente evidente?, puedes usar rpmdb-redhat (la base de datos de todos los paquetes oficiales de esa distribución) o urpmi o apt. Todos ellos añaden la posibilidad de resolver las dependencias sin consultar los paquetes.

Por ejemplo, en RedHat con rpmdb-redhat podría hacer:

$ rpm -q --redhatprovides tuxracer

O lo que fuera que quisieras comprobar y perteneciente a un paquete que no estuviera instalado pero que existiera en la distribución.

Otra solución de otro tiempo es preguntar en tu cd. Algo como:

for i in /cdrom/*.rpm ; do
[ -n "$(rpm -qp --provides $i | grep ORBit)" ] && echo $i && break
done


Pero vamos, eso es anterior al descubrimiento del fuego. Mucho antes de que los paquetes deb soportaran algo tan elemental como las firmas digitales, sin duda :-).

Resumiendo que nos van a echar:

Deb tiene más potencia al incluir campos como suggest, conflict o pre-depend


Que yo sepa, conflict tiene su reflejo en rpm (calculados automáticamente o a gusto del usuario). Por ejemplo, consulta "conflicts" y "obsoletes". Pre-depend no tiene sentido en rpm, porque todas las dependencias son "pre-depend". Vamos, que no se instala un paquete (los archivos) y luego te deja tirado el instalador (sin hacer la configuración final) al faltar dependencias. En rpm o están todas las dependencias o no se copia ni un archivo (lo cual me gusta y lo contrario no me gusta, que es lo hace deb por defecto).

Deb tiene muchas más herramientas, con mayores posibilidades de configuración y mayor potencia

¿Y me mencionas dselect?. Venga ya X-). Ten en cuenta que rpm tiene mucha más funcionalidades que dpkg por si sólo (por ejemplo, con rpm no hace falta un lento debsums en perl ya que desde el mismo rpm se puede verificar la integridad del sistema). Es normal que haya muchas más aplicaciones complementarias para dpkg que para rpm, que es mucho más completo.

Además, si la gente tiene que escribir tanta herramienta para manejar los paquetes será porque fallan las originales :-P.

En fin, para gustos los colores... Pero para mí, el sistema de paquetes de Debian está claramente sobrevalorado. O eso o hay algo que se me escapa :-).

Otra cosa, ¿cómo se resuelve en deb el tema de tener instalados dos paquetes iguales pero de distinta versión?. Ojo, que no lo sé y no va con doblez :-): me acabo de dar cuenta de que eso aún no lo he visto funcionando (al menos, no en Debian) y sí en distribuciones basadas en rpm, por ejemplo, y va un poco al hilo de lo que comentabas de tener los dos KDE instalados al principio. ¿Es una (otra) limitación de deb?.

[ Padre ]


urpmi mola | 18 comentarios (18 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda