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)
Post, pre y postun (none / 0) (#12)
por jorginius ("jorginius" en Google Mail) a las Mon Jul 21st, 2003 at 03:48:13 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Ejem....libfontconfig1 (>= 2.1), /bin/sh , /bin/sh , /bin/sh ,rpmlib(PayloadFilesHavePrefix) (<= 4.0-1),.....>

Vale sí, pero no :-). ¿Sabes de donde salen /bin/sh?:

$ rpm -q --scripts
[...]
postinstall scriptlet (using /bin/sh):
[...]


Es decir, son dependencias del proceso de instalación (los scripts de pre, postinstall y postuninstall se ejecutan vía /bin/sh, por eso las tres ocurrencias (pre, post y postun). Salen justo de lo que no hace deb, de considerar las dependencias de los scripts de instalación.

Vaya, pues la respuesta me parece de cajón, imagínate que no tengo instalado libkdefakes.so.4

No tienes instalada libkdefakes.so.4, tendrás a lo sumo /usr/lib/libkdefakes.so.4.x u otra biblioteca instalada con el soname libkdefakes.so.4. Para saber que paquete cumple tal o cual dependencia no se usa "-f", que sólo pregunta por el archivo sino "-q --whatprovides".

¿en que paquete estará?, pues hay que hacer rpm -f que no se si funcionará con paquetes no instalados,

No, no funciona con paquetes no instalados ya que se consulta la base de datos local, igual que dpkg sabe sólo de los paquetes que están instalados. Es apt (o urpmi) el que maneja la lista completa de paquetes (instalados y sin instalar de cada repositorio) y calcula todas las dependencias. Ambas herramientas externas. En el caso de apt hace su trabajo indistíntamente de si manejan debs o rpms.

y eso teniendo en cuenta que esté en un sólo archivo ¿y si hay dos versiones con el mismo, incompatible uno con otro

En ELF no puede haber dos bibliotecas con el mismo soname e incompatibles entre sí (bueno, por poder... Pero es patológico). Luego si hay bibliotecas con el soname libkdefakes.so.4 en sendos paquetes, una puede reemplazar a la otra.

Si el soname es distinto, la cuestión de que pasa si uno reemplaza a otro carece de sentido puesto que la incompatibilidad, más allá de las dependencias, es a nivel binario (el cargador ld-linux.so no sabrá resolver el enlazado al crearse la imagen del proceso al no encontrar la equivalencia soname<->biblioteca correspondiente): rpm instalará ambos paquetes independientemente o avisará de que se intenta reemplazar un paquete viejo con uno nuevo pero que no cubre las dependencias del viejo, lo que muestra un paquete mal hecho.

Si el paquete nuevo no esta marcado como reemplazo del otro y aún así provee el mismo soname, rpm notificará una colisión (dos paquetes proveen la misma dependencia de bibliotecas pero no son equivalentes) y no se instalará la nueva versión a menos que el usuario lo fuerce. Huelga decir que esto no ocurre nunca con paquetes de una misma distro.

Y aún con todo, observa que aparece una dependencia de paquete (kdelibs (>= 3.1.2-9.3)).

Creo que aquí no te explicas bien ¿quieres decir que quieres el servidor ssh pero no el cliente?, entiendo que sea por motivos de espacio, pero por seguridad no creo

Si alguien se cuela en una máquina detras del primer cortafuegos y consigue una shell, no quiero que tenga el cliente ssh para intentar dar el salto a los otros servidores o al router. Ahora mismo es un mini-problema porque por necesidades del guión no podemos evitar que los sshd de los servidores escuchen todos en la misma red entre el cortafuegos externo y el cortafuegos de una de las redes internas. Es sólo una medida más. Además, es que no tiene sentido: si sólo quiero el servidor, ¿para qué tengo que instalar además el cliente?.

No sé que problema has tenido pero seguramente trataste de instalarlo con dpkg -i, te dió dependencias incorrectas [...]

Pues no, fue con "apt-get install" y haciendo "apt-get install -f" lo único que conseguía era que volviera a salir el mensaje de que con "apt-get install -f" se arreglaría el problema (divertido fallo recursivo: me recuerda a cuando falla el depurador del MS Visual C++ o el kdbg y te sale el recuadro de "¿desea depurar?" :-)).

Eso se llama problema de scripts de configuración ;-), no de dependencias, y puede pasar con un rpm también, si por ejemplo fallan los scripts de %post que son los ejecutados tras ser instalado

El problema es que los scripts necesitaban de un paquete que no estaba instalado y que no se lista en la descripción de dependencias. En rpm se incluyen automáticamente las dependencias de esos scripts, no así en deb.

Por otro lado, un fallo de este tipo no deja la base de datos de rpm en un estado inconsistente, como pasa con deb.

De lo más habitual son las "dependencias circulares": paquetes que dependen de paquetes que a su vez dependen de los primeros.

¿Habitual?, ni una sola vez me he encontrado con eso que dices,

Porque apt lo esconde a tus ojos :-). Intenta dejar unos cuantos servidores corriendo y desintala todo lo que puedes alrededor. Te encontrarás con cosas de esas (paquetes que no puedes deinstalar porque dependen de otros paquetes que tampoco puedes deinstalar por separado, por depender de los primeros). O desintalas los dos a la vez o nada, así que no es muy normal que haya dos paquetes separados, pienso yo.

Por "Habitual" hay que entender como que he visto un par de cosas de esas en ciento y pico paquetes :-). No es que sea la norma, pero esas anomalías haberlas haylas, como las meigas... Y en la estable.

[ Padre ]


Por partes... (none / 0) (#14)
por melenas a las Mon Jul 21st, 2003 at 04:48:47 PM CET
(Información Usuario)

Es decir, son dependencias del proceso de instalación...blah, blah

Si tú lo dices yo me lo creo ;-)

Para saber que paquete cumple tal o cual dependencia no se usa "-f", que sólo pregunta por el archivo sino "-q --whatprovides".

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 ;-)

En ELF no puede haber dos bibliotecas con el mismo soname e incompatibles entre sí...

No, no, yo me refiero a dos paquetes que contengan el mismo archivo, el mismo soname, pero que uno sea incompatible con otro por otras causas, ¿como resuelves la dependencia?¿cual de los dos eliges?, al tener las dependencias orientadas a archivos con rpm -q --whatprovides te dará dos archivos ¿cuál eliges?, y ya sé que rpm también puede depender de paquetes pero aquí estamos hablando de archivos aunque el soname representa a 2 ó 3.

Si alguien se cuela en una máquina detras del primer cortafuegos y consigue una shell, no quiero que tenga el cliente ssh para intentar dar el salto a los otros servidores o al router.

En ese caso usa PAM, y si no te convence, siempre puedes escribir al empaquetador, o simplemente borrar el ejecutable o quitarle permisos de ejecución, al menos puedes elegir, yo no puedo elegir que programas de KDE instalar sin tener que elegir el paquete entero, pero es más bien tema de cómo se empaqueta y no de la calidad del sistema.

El problema es que los scripts necesitaban de un paquete que no estaba instalado y que no se lista en la descripción de dependencias. En rpm se incluyen automáticamente las dependencias de esos scripts, no así en deb. Por otro lado, un fallo de este tipo no deja la base de datos de rpm en un estado inconsistente, como pasa con deb.

De nuevo me comentas un fallo del empaquetador y no del sistema de empaquetamiento, si el script hace por ejemplo una llamda a perl y este no está instalado ni está en las dependencias, es problema del empaquetador y no del sistema, en esos casos debes reportar el fallo al empaquetador. Con respecto a bases de datos inconsistentes, yo sólo lo he visto en Access ;-)

Porque apt lo esconde a tus ojos :-). Intenta dejar unos cuantos servidores corriendo y desintala todo lo que puedes alrededor. Te encontrarás con cosas de esas (paquetes que no puedes deinstalar porque dependen de otros paquetes que tampoco puedes deinstalar por separado, por depender de los primeros). O desintalas los dos a la vez o nada, así que no es muy normal que haya dos paquetes separados, pienso yo. Por "Habitual" hay que entender como que he visto un par de cosas de esas en ciento y pico paquetes :-). No es que sea la norma, pero esas anomalías haberlas haylas, como las meigas... Y en la estable.

Pues yo controlo ocho debians, cuatros servidores (dos montadas por Super-BOFH, una stable y otra unstable, y otras dos por mí stables), 3 de escritorio, sid con KDE 3.1.2, sid con KDE 3.2 y woody con KDE 3.1.2, más en mi casa sarge con KDE 3.1.2 y no he tenido ningún problema que me comentas, y mira que meto repositorios "no oficiales" e incluso programas empaquetados por mí (para que veas que me arriesgo al máximo XD), y ninguna dependencia circular ni paquetes a medio instalar, a menos que dependiese de un paquete no disponible en ese momento que rompiera el resto de dependencias.

Resumiendo que nos van a echar:
  • Deb tiene más potencia al incluir campos como suggest, conflict o pre-depend que le da más maniobrabilidad.
  • Deb tiene muchas más herramientas, con mayores posibilidades de configuración y mayor potencia (apt-get, dselect, aptitude, dpkg, dpkg-awk, jablicator, debconf, make-kpkg...) mientras que rpm tiene rpm y urpmi
  • En ambos lados hay torpedos que no saben empaquetar ;-)
  • Hay en ambos lados programas que no nos gustan como están empaquetados


El resto (a mí me jodió la base de datos, pues yo rpm como no sea con --nodeps ni se instala...) son poco más que apreciaciones personales que a poco o nada llevan...

Ea, pues un saludo y un placer debatir abiertamente contigo :-)


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
[ Padre ]


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