Contestaré aquí a tu comentario y al del sinner de más abajo.
En rpm puedes definir dependencias en función de archivos, de paquetes o abstractas (tipo "cualquier mta"). Que en el principio de los tiempos se definieran las dependencias de la forma que comentas en RedHat y derivados no fue por una limitación de RPM.
Y al melenas: ya te vale. Los rpms los haces como quieras, dependientes de ficheros o de paquetes o similares. Que los empaquetadores aficionaos sean unos torpedos, no quiere decir que en rpm no se puedan hacer las cosas bién.
Bueno dependencias sacadas del paquete kdebase-3.1.2-9.4tex.i586.rpm de los de texstar que usé para actualizar mi KDE a 3.1.2
rpmlib(VersionedDependencies) (<= 3.0.3-1), kdelibs (>= 3.1.2-9.3), libqt3 (>= 3.1.2-9.1), liblm_sensors1 , libmp3lame0 , notlame , arts (>= 1.1.2), kdm , mdk-menu-messages (>= 9.1), galaxy-kde-kwin , mdklaunchhelp (>= 9.1), mandrake-mime (>= 0.3), krootwarning (>= 9.1), kdebase-servicemenu , initscripts (>= 7.04), kdelibs (>= 3.1.2), libfontconfig1 (>= 2.1), /bin/sh , /bin/sh , /bin/sh , rpmlib(PayloadFilesHavePrefix) (<= 4.0-1), rpmlib(CompressedFileNames) (<= 3.0.4-1), appletproxy.so , extensionproxy.so , kaccess.so , kate.so , kcminit.so , kcmshell.so , kcontrol.so , kdesktop.so , keditbookmarks.so , kfmclient.so , khotkeys.so , kicker.so , kjobviewer.so , klipper.so , kmenuedit.so , konqueror.so , konsole.so , kprinter.so , ksmserver.so , kwin.so , kwrited.so , kwrite.so , kxkb.so , ld-linux.so.2 , libart_lgpl_2.so.2 , libc.so.6 , libDCOP.so.4 , libdl.so.2 , libexpat.so.0 , libfam.so.0 , libfontconfig.so.1 , libfreetype.so.6 , libgcc_s.so.1 , libGL.so.1 , libICE.so.6 , libjpeg.so.62 , libkabc.so.1 , libkateinterfaces.so , libkatepartinterfaces.so.0 , libkdecore.so.4 , libkdefakes.so.4 , libkdefx.so.4 , libkdeprint_management.so.4 , libkdeprint.so.4 , libkdesu.so.4 , libkdeui.so.4 , libkhtml.so.4 , libkickermain.so.1 , libkio.so.4 , libkmultitabbar.so.0 , libkonq.so.4 , libkonsolepart.so , libkparts.so.2 , libkscreensaver.so.4 , libkscript.so.0 , libksgrd.so.0 , libktexteditor.so.0 , libkutils.so.1 , liblcms.so.1 , libmng.so.1 , libm.so.6 , libpam.so.0 , libpng.so.3 , libpthread.so.0 , libqt-mt.so.3 , libresolv.so.2 , libsensordisplays.so.0 , libsensors.so.1 , libSM.so.6 , libstdc++.so.5 , libutil.so.1 , libvcard.so.0 , libX11.so.6 , libXext.so.6 , libXft.so.2 , libXmu.so.6 , libXrandr.so.2 , libXrender.so.1 , libXt.so.6 , libXtst.so.6 , libz.so.1 , libartsflow_idl.so.1 , libartsflow.so.1 , libartskde.so.1 , libasound.so.2 , libaudiofile.so.0 , libaudio.so.2 , libcrypto.so.0.9.7 , libcrypt.so.1 , libgdbm.so.2 , libkdesasl.so.1 , libkmedia2_idl.so.1 , libkmid.so.0 , libkonqsidebarplugin.so.0 , libkonq_sidebar_tree.so , libkspell.so.4 , liblber.so.2 , libldap.so.2 , libmad.so.0 , libmcop.so.1 , libnsl.so.1 , libogg.so.0 , libqtmcop.so.1 , libsasl.so.7 , libsoundserver_idl.so.1 , libssl.so.0.9.7 , libtaskbar.so.1 , libtaskmanager.so.1 , libvorbisenc.so.2 , libvorbisfile.so.3 , libvorbis.so.0 , libc.so.6(GLIBC_2.0) , libc.so.6(GLIBC_2.1) , libc.so.6(GLIBC_2.1.3) , libc.so.6(GLIBC_2.2) , libc.so.6(GLIBC_2.3) , libgcc_s.so.1(GLIBC_2.0) , libm.so.6(GLIBC_2.0) , libpthread.so.0(GLIBC_2.0) , libstdc++.so.5(GLIBCPP_3.2) , libutil.so.1(GLIBC_2.0)>
Ahora dependencias del paquete kdebase que viene oficialmente con la Mandrake 9.1. Siento el SPAM XD
>
rpmlib(VersionedDependencies) (<= 3.0.3-1), kdelibs (= 3.1), arts , kdm , mdk-menu-messages (>= 9.1), galaxy-kde-kwin , mdklaunchhelp (>= 9.1), mandrake-mime (>= 0.3), krootwarning (>= 9.1), kdebase-servicemenu , initscripts (>= 7.04-3mdk), kdelibs (>= 3.1-54mdk), libfontconfig1 (>= 2.1-9mdk), /bin/sh , /bin/sh , /bin/sh , rpmlib(PayloadFilesHavePrefix) (<= 4.0-1), rpmlib(CompressedFileNames) (<= 3.0.4-1), appletproxy.so , extensionproxy.so , kaccess.so , kate.so , kcminit.so , kcmshell.so , kcontrol.so , kdesktop.so , keditbookmarks.so , kfmclient.so , khotkeys.so , kicker.so , kjobviewer.so , klipper.so , kmenuedit.so , konqueror.so , konsole.so , kprinter.so , ksmserver.so , kwin.so , kwrite.so , kwrited.so , kxkb.so , ld-linux.so.2 , libDCOP.so.4 , libGL.so.1 , libICE.so.6 , libSM.so.6 , libX11.so.6 , libXext.so.6 , libXft.so.2 , libXmu.so.6 , libXrender.so.1 , libXt.so.6 , libXtst.so.6 , libart_lgpl_2.so.2 , libc.so.6 , libdl.so.2 , libexpat.so.0 , libfam.so.0 , libfontconfig.so.1 , libfreetype.so.6 , libgcc_s.so.1 , libjpeg.so.62 , libkabc.so.1 , libkateinterfaces.so , libkatepartinterfaces.so.0 , libkdecore.so.4 , libkdefakes.so.4 , libkdefx.so.4 , libkdeprint.so.4 , libkdeprint_management.so.4 , libkdesu.so.4 , libkdeui.so.4 , libkhtml.so.4 , libkickermain.so.1 , libkio.so.4 , libkmultitabbar.so.0 , libkonq.so.4 , libkonsolepart.so , libkparts.so.2 , libkscreensaver.so.4 , libkscript.so.0 , libksgrd.so.0 , libkspell.so.4 , libktexteditor.so.0 , libkutils.so.1 , liblcms.so.1 , libm.so.6 , libmng.so.1 , libpam.so.0 , libpng.so.3 , libpthread.so.0 , libqt-mt.so.3 , libresolv.so.2 , libsensordisplays.so.0 , libstdc++.so.5 , libutil.so.1 , libvcard.so.0 , libz.so.1 , libartsflow.so.1 , libartsflow_idl.so.1 , libartskde.so.1 , libasound.so.2 , libaudio.so.2 , libaudiofile.so.0 , libcrypt.so.1 , libcrypto.so.0.9.7 , libgdbm.so.2 , libkdesasl.so.1 , libkmedia2_idl.so.1 , libkmid.so.0 , libkonq_sidebar_tree.so , libkonqsidebarplugin.so.0 , liblber.so.2 , libldap.so.2 , libmad.so.0 , libmcop.so.1 , libnsl.so.1 , libogg.so.0 , libqtmcop.so.1 , libsasl.so.7 , libsoundserver_idl.so.1 , libssl.so.0.9.7 , libtaskbar.so.1 , libtaskmanager.so.1 , libvorbis.so.0 , libvorbisenc.so.2 , libvorbisfile.so.3 , libc.so.6(GLIBC_2.0) , libc.so.6(GLIBC_2.1) , libc.so.6(GLIBC_2.1.3) , libc.so.6(GLIBC_2.2) , libc.so.6(GLIBC_2.3) , libgcc_s.so.1(GLIBC_2.0) , libm.so.6(GLIBC_2.0) , libpthread.so.0(GLIBC_2.0) , libstdc++.so.5(GLIBCPP_3.2) , libutil.so.1(GLIBC_2.0)>
Pfff, si habéis llegado hasta aquí os habréis dado cuenta que todavía siguen anclados en dependencias individuales y llamar aficionados a los de textar o los propios de Mandrake, pues no sé, es como tirar piedras a tu propio tejado ;-).
Yo creo que URPMI (que son varios scripts hechos en perl), pilla las dependencias de archivos, le hará un rpm -f "nombre_fichero_del_que_depende" o lo buscará en los/el repositorio/s, pero no me parece una forma "limpia" de hacer las cosas, parece como forzado, eso sí funcionar funciona, pero un poco cogido de los pelos ya que no hay una política clara de dependencias y demás.
Nunca he entendido muy bien por qué los usuarios de Debian consideran el sistema de dependencias de rpm inferior. O el mismo rpm inferior a deb.
Yo sí y paso a enumerar:
- Muchas más aplicaciones como ya dije antes, apt-get, dpkg, dpkg-awk, dselect, aptitude o jablicator que permite coger una distro y hacer un dep con dependencias con todo lo instalado para poder replicarlo en otra máquina. Ya sé que Mandrake tiene kickstart, pero además de que tiene que estar en un disquette, sólo se puede utilizar instalándolo, no después de hacerlo.
- debconf: el que te instales un servidor y te haga una serie de preguntas para configurarlo automáticamente es lo más, y además en modo texto que para mis servidores sin X-Window me es muy útil, por ejemplo mysql te pregunta si quieres que te abra un puerto de escucha remoto, además si te bajas el mod para Apache te pregunta si quieres que modifique él solito el archivo de configuración del mismo y reiniciar el servidor web para que coja los cambios, sólo falta que llame por teléfono a la rubia para quedar con ella por la noche XDD
- Los campos suggest, conflict, pre-depends, que no sé si existen en RPM, pero he visto algunos y no los veo por ninguna parte. Con suggest, sugieres paquetes que no son imprescindibles, pero que mejoran las funcionalidades del instalado, conflict permite eliminar un paquete con el que hace conflicto aunque el que instales no sea una versión superior, por ejemplo cuando pasas de woody a sarge hay tres paquetes en el primero que son sustituidos por uno del segundo
- Además se va a añadir un nuevo campo que creo que daba más o menos importacia al paquete, pero ahora no encuentro donde lo leí
- make-kpkg para compilar tu núcleo para la máquina pentium en un pentium IV, empaquetándolo en un deb, sé que hay núcleos y módulos empaquetados en rpm, pero yo no sé como lo hacen, en Debian sí y es muy fácil, y en cuanto compilas uno, no sabes la pérdida de tiempo que es make , make install, make modules etc...
Encuentro las consultas de la base de datos de paquetes en Debian muy, muy lentas por ser texto plano y el apt no hace más que agravarlo, al tener que recalcular sobre esa base de datos las dependencias necesarias cada vez que se ejecuta.
Yo no los encuentro tan lento, pero date cuenta que apt-get hace mucho más que rpm o urpmi como he explicado arriba.
Tampoco me gusta de deb que deje los paquetes a medio instalar si no se satisfacen las dependencias o que no compruebe las dependencias de los scripts de post y de pre instalación. Te puedes encontrar con un paquete que, como parte del proceso de instalación (no como una dependencia normal), dejando todo el proceso en un estado inconsistente. Eso creo que nos pasó con phpmyadmin o chora y un paquete de perl para hablar con mysql que no teníamos pero que la instalación requería (y que no nos notificaba en ninguna parte). Hubo que visitar luego los logs, ver dónde fallaba la instalación, retocar la base de datos de paquetes para poder desinstalar, instalar previamente el paquete que faltaba y reintentar. Un proceso transparente :-)
Como diría mi amigo JJ de Linux Sevilla, ESO ES DEMAGÓGICO, el deb nunca termina de instalarse hasta que esté todo perfectamente configurado y si te da problemas de dependencias es por culpa de uno mismo o como dice Sinner hay algunos torpedos que no empaquetan bien. Yo por ejemplo tuve un problema cuando compilé mi propio núcleo 2.4.18 y no sé porque, me dió por instalar el 2.4.18 de Debian, claro, el paquete detectó un directorio /lib/modules/2.4.18 y me dijo que no quería machacarlo, pero claro, al desinstalarlo me decía que borraría el el susodicho directorio dejándome sin módulos. Estaba claro que era una pifiada mía por no compilar a la Debian. Pero aparte de eso que finalmente solucioné instalando forzado un 2.4.20 ni un sólo problema, a menos que haga cosas como instalar KDE 3.1 de Woody en Sarge.
Tampoco entiendo como han empaquetedo muchos paquetes en Debian. Por ejemplo, no sé por qué el servidor y el cliente de ssh comparten paquete cuando tienden a disgregar todo lo demás hasta límites enfermizos. Pero eso ya no tiene que ver con el pobre deb, supongo ;-)
Como ya he explicado anteriormente, cuando instalas ssh, con debconf te pregunta en un perfecto español si quieres iniciar el servidor ssh además de otras preguntas. Si quieres reconfigurarlo en post-instalación haces "dpkg-reconfigure ssh" y ya está. Supongo que el que esté junto o separado es cuestión de gustos, pero puedes hacerle un wish al empaquetador que supongo tendrá sus razones.
Y para quien quiera saberlo, sí, he trabajado con RPM durante 3 años desde la SuSE 6.4 hasta Redhat 7.3 pasando por SuSE 7.0, Mandrake 8.0, 8.1 y 8.2, y Lycoris y aunque Debian en principio me pareció un coñazo imposible de instalar, en cuanto te acostumbras te preguntas que leche hacías con las otras distros.
Hoy por hoy si hay un sistema de paquetes superior tendrá que ser el de Gentoo, no lo he probado y por eso no puede ni afirmarlo ni desmentirlo, pero el hecho de poder tener KDE 3.1.2 y KDE 3.2 en la misma máquina, hace que me piense seriamente el probarlo.
Espero no haber sido muy leñazo, saludos y hasta otra.
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 ]
|