🚀 go-pugleaf

Hola, se�or Albi�ana:

Benjam�n Albi�ana P�rez wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>  Cuando: Tue, 10 Oct 2000 10:20:33 +0200
>  Quien: NAVARRO LOPEZ <hostmaster@promofinarsa.es>
>  Que: Re: Librerias en linux
> 
> >c�mo sabemos, sobre la marcha, cu�les son los ficheros que
> >incluye el deb en cuesti�n (el del exim, sendmail, o el que
> >sea) ya que el posible problema que mencionaba estaba, no
> >en los programas sino en las librer�as.  El problema
> >potencial no es que me avise de que se va a actualizar un
> >bloque-programa (cosa que tambi�n te dir� rpm, por
> >ejemplo), sino saber que en ese bloque-programa se incluye
> >las (digamos) nuevas versiones de las librer�as de ssl, y
> >lo m�s importante, saber que, desgraciadamente, son
> >incompatibles con el tgz de ssh que compil�/instal�
> >antesdeayer, que es de lo que se trataba.
> 
>   No s� si entiendo bien la cuesti�n. �Es que un rpm trae
>   sus propias librer�as en el paquete? En un .deb, si algo

S� y no: no hay nada que diga o deje de decir lo que *tiene que ir*
dentro de un rpm (y, me imagino, lo mismo ocurre con un deb).  En
general, manda el sentido com�n, claro: si un programa usa una librer�a
desarrollada por terceros, normalmente se indicar� la dependencia de un
paquete que la contenga y a otra cosa.  Pero si un grupo de desarrollo
genera sus propias librer�as para un programa, har� lo que le parezca. 
Camino habitual suele ser (lo he visto en alguna ocasi�n, con HylaFax, o
con mysql, por ejemplo) es que se empiece publicando un s�lo paquete y,
si el programa tiene �xito, como suele aumentar su tama�o y/o sus
librerias pueden ser usadas por otros programas, el paquete original se
"rompa" como parezca oportuno (librer�as por un lado, documentaci�n por
otro, si es cliente/servidor los servidores a un lado, los clientes a
otros, etc.).  Hay aqu� dos cosas: por un lado, esto que te digo no
tiene nada que ver con el hecho de que estemos hablando de rpms, debs,
tarballs o lo que sea, sino con estrategias de manejo de
configuraciones.  Por otro lado, el origen de este hilo (o de esta
derivaci�n del hilo) no era tanto el uso de tal o cual librer�a como del
manejo de las *versiones* de una librer�a dada y del hecho de que,
trat�ndose de software de libre distribuci�n, se le tenga muy poco
respeto a la compatibilidad hacia atr�s, de manera que los problemas
surgen no tanto en el manejo de dependencias, como con el control de
versiones v�lidas: lo que indicaba es que, a mi entender, aparte de lo
buenas o malas que sean sus herramientas para el manejo de
configuraciones, Debian tiene una ventaja que no tienen las
distribuciones basadas en rpm y es, justamente, que en el caso de Debian
hablamos de Debian, y en el de "las distribuciones rpm" pues eso, de
m�ltiples distribuciones, con m�ltiples empaquetadores de un paquete
dado (sea de librer�as o no) y para m�ltiples distribuciones similares,
pero no id�nticas, lo que limita las presunciones que puedes hacer con
respecto al proceso de instalaci�n de un paquete.  Como tambi�n dec�a,
apt puede ser muy ergon�mico, pero el manejo de paquetes rpm no
*tendr�a* porqu� serlo menos (quiero decir, contiene la funcionalidad
suficiente -en realidad, si no estoy mal informado, Mandrake est�
trabajando en una herramienta similar al apt para rpm �no?-) si no fuera
porque un programador independiente, a la hora de generar un rpm tiene
que optar por una ley de m�nimos para que pueda instalarse, m�s o menos
sin problemas, lo mismo en RH que en SuSE, que en Mandrake, etc.

>   depende de algo, aparece en el campo depends, y si haces
>   un apt get install, te dir� que va a instalar ese
>   programa, las librer�as que hagan falta, y a borrar lo que
>   sea necesario. "Desea continuar Y/n".

Ya, y por defecto una instalaci�n rpm te dice, por ejemplo, dependencia
incumplida con 'unalibreria.so'.  El problema de las librer�as que se
achaca a rpm est� en que no te dice 'dependencia con el paquete rpm
nosecuantos', sino con la librer�a que sea y te tienes que buscar t� el
paquete, pero esto no es una limitaci�n del formato rpm sino, como
dec�a, de que el desarrollador del rpm no dispone de un paquete
"oficial" para esa librer�a.

>   Si por ejemplo quieres, no se me ocurre ahora mismo, pero
>   imaginemos que tenemos el paquete desemacscareitor en
>   woody, y depende de libprrrrrt-1.2.b-1 que hace conflicto
>   con la que tienes instalada. Tienes tres opciones, tiras
>   p'alante, esperas a que salga ese paquete para tu release,
>   o intentas compilarlo contra las librer�as que tienes en
>   tu sistema, con apt-get source --compile. Esto �ltimo, a
>   veces funciona, a veces no. Y aqu� ya me meto en terreno
>   que no conozco bien, as� que no puedo decir m�s.
> 
>   Lo que s� tengo claro es que no hace nada que el admin no
>   le pida.
> 

Ya.  �Pero de d�nde saca apt la informaci�n de lo que est� instalado y
lo que no? si te sales del propio manejador de paquetes deb (instalando
un programa/librer�a por tu cuenta desde un tarball, pe) c�mo va a saber
apt que cambiar cierta librer�a por la nueva versi�n no va a cascar el
programa? Y aunque el programa se hubiese instalado como deb, c�mo a
saber si puede actualizar la librer�a si el paquete no le dice que tiene
una dependencia *estricta* con la versi�n X.Y.Z de unalib.so, o se
permite una versi�n mayor o igual de X.Y.Z (y aqu� hay una trampa:
cuando el desarrollador dijo X.Y.Z o mayor, lo dijo porque sab�a que
X.Y.Z+3 no daba problemas, pero dentro de seis meses igual s� los da con
X+1.J.K).  Lo que ven�a a decir en origen (cuando el primer contertulio
dec�a que este tipo de problemas pasaba con Linux, pero no con Win) es
que este tipo de problemas aparecen (tienen que aparecer, teniendo en
cuenta c�mo se construye actualmente el software) independientemente del
sistema operativo o del modelo de distribuci�n/instalaci�n/configuraci�n
de software que emplees (aunque, claro, seg�n lo que hagas podr�s
tenerlo m�s o menos controlado).

-- 
SALUD,
Jes�s
***
jesus_navarro@promofinarsa.es
***