Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
urpmi mola

man ls's Diary
Por man ls
departamento agradecimientos varios , Sección Diarios
Puesto a las Sat Jul 19th, 2003 at 02:31:02 PM CET
Olvidad completamente el título mi última entrada: nada de Robinsón español. Sí, al principio uno se puede sentir un poco aislado y tal, delante de su monitor y a su bola; pero <himno pais="Libertonia">en libertonia nunca estarás solo<himno>.

 


Pues sí, amigos: gracias a la inestimable ayuda de dodger, especialmente al urpmi howto, ya he instalado urpmi. Aclaro que, en la página de VLC para mandrake, viene una ayuda muy clara.

Reconozco que ya era carne de Debian, gracias a los resultados de la encuesta y a la envidia que me daba ver los vaciles de los adeptos de Debian. Pero me mantuve fuerte, y me resistí a bajármelo (sobre todo porque hay 515 imágenes ISO de Debian y no tenía ganas de ir a comprar cedeses). Ah, las nunca-bien-ponderadas virtudes de la pereza.

Así que ya he colocado fuentes de paquetes para todo, incluyendo PLF (Penguin Liberation Front), necesario para bajarse las librerías "ilegales" 'libdvd.*'. Ya tengo mi vlc andando, por fin podré probar a reproducir esos VideoCDs que MPlayer se niega a leer. Sigo teniendo mil preguntas, pero para no ser demasiado porculero no las haré todas de golpe.

Cada vez me mola esto más, le estoy pillando el gusto a eso de cacharrear. ¿Me convertiré en un auténtico hacker? Y, más importante, ¿debería cambiar mi nombre de usuario una vez que supere la fase de man ls? ¡Tu opinión importa!

< Mozilla mirará al usuario final (6 comments) | Llega 2.6.0-test (15 comments) >
Enlaces Relacionados
· escomposlinux.org
· mi última entrada
· la inestimable ayuda de dodger
· urpmi howto
· en la página de VLC para mandrake
· los resultados de la encuesta
· los vaciles de los adeptos de Debian
· hay 515 imágenes ISO de Debian
· PLF
· More on man ls's Diary
· Also by man ls

Encuesta
¿Cambio mi username?
· no, está bien 15%
· no que nos lías 30%
· ve actualizándolo 0%
· ponte 'man urpmi' 0%
· ponte 'indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl "$@" *.c' si tienes cohone 19%
· se encarga el BOFH de guardia con 'rm -f /home/man_ls'... 34%

Votos: 26
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
urpmi mola | 18 comentarios (18 temáticos, editoriales, 0 ocultos)
Al final... (none / 0) (#1)
por sinner a las Sun Jul 20th, 2003 at 01:43:57 AM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Al final acabareis todos con Mandrake, ya lo veo. Esto es el principio.

MWAHAHAHAHAHA


En serio, ¿a que mola urpmi?

Pues crearse repositorios "urpmi-zados" no es tan dificil. Necesitas "genhdlist", que te viene en "rpmtools". Te vas al directorio de tus rpms (/home/man_ls/downloads/rpms/ por ejemplo), y escribes: "genhdlist ./" y ya ta.

Utilísimo para esos roms que te bajas por doquier... o que te creas con chkinstall (http://libertonia.escomposlinux.org/story/2002/10/25/53113/319).

Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org


No creo.. (4.50 / 2) (#2)
por melenas a las Sun Jul 20th, 2003 at 01:13:28 PM CET
(Información Usuario)

Aunque me gusta Mandrake y le tengo siempre una partición guardada en mi disco duro, para mí Debian es mejor por varias razones:
  • Sistema de paquetes:Mientras RPM para sus dependencias se basa en archivos individuales, DEB por el contrario lo hace por otros paquetes, lo que le da, en mi opinión una mejor organización y claridad, no debes buscar a que paquete pertenence un archivo en particular. He estado viendo los últimos paquetes de Mandrake y parece que está pasando a utilizar el sistema DEB de dependencias por paquete, pero todavía lleva el lastre las dependencias "individuales".
  • Instalación:Aunque URPMI apunta muy buenas maneras, aún le queda como diría Gonzo, "unos hervores", frente a la gran cantidad de opciones de apt-get, dpkg y dpkg-awk, a urpmi le veo un poco falto de ellos. Además de que sus archivos de repositorio los encuentro demasiado crípticos como los de "synthesis" que frente a los available me suena a chino. Y es que cuando con el comando:
    dpkg-awk -f /var/lib/dpkg/available 'Depends:.*kdelibs4.*' | egrep Package: | cut -d \ -f2 | xargs apt-get install -s
    te instalas todo lo que haya de KDE3, pues que el urpmi no termina de convencerme, y no digo que no se pueda hacer, pero que si se puede, debe de costar mucho trabajo.
  • La forma de empaquetar KDE: Es lo que menos me gusta, eso de meterlo todo en metapaquetes, por ejemplo, en Debian puedo querer Konqueror y Kmail, pero no Knewsticker ni Knode, sin embargo en Mandrake al venir todo junto en un rpm, te lo tienes que instalar TODO. Obviamente en Debian también existe el paquete kdenetwork, que es un metapaquete con dependencias a todos los programas de red de KDE, que en Debian es opcional, en Mandrake si quieres konqueror y/o Kmail no.
  • Lenta:Aunque compilada para 586, la encuentro muy lenta al arrancar, y sí, le tengo quitado todos los servidores y aún así Debian tarda menos


Pero aún así la encuentro una muy buena distribución, aunque no mi preferida ;-), sin embargo todo el mundo que me conozca sabrá que trato de coger todas las cosas buenas de Mandrake y pasarselas a Debian.

Yo creo que cada una debe de aprender de la otra, así que mientras Mandrake trata de aprender del sistema de actualizaciones de Debian, Debian trata de aumentar su autodetección ¿Knoppix?

Y con respecto a crear paquetes y sus repositorios, yo uso también checkinstall ;-), aunque después lo modifico para ponerle las dependencias, y la creación del repositorio es tan fácil de hacer como:

dpkg-scanpackages dists/stable/main/binary-i386 /dev/null | gzip -9> dists/stable/main/binary-i386/Packages

Cortesía de Javi Cantero ;-)


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 ]


Sobre RPM (4.00 / 1) (#5)
por jorginius ("jorginius" en Google Mail) a las Mon Jul 21st, 2003 at 01:00:38 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

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.

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. A mí me parece justo todo lo contrario, sobre todo en velocidad y facilidad para crear nuevos paquetes. Sobre la flexibilidad no hablo, porque no tengo tanta experiencia en deb como en rpm, pero al menos diría que son similares.

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. Nunca he entendido por qué se jactan de ser respetuosos con máquinas pequeñas (como un 386) e incluyen un sistema de paquetes que esas pobres máquinas mueven a duras penas.

¿Las ventajas que le veo al deb?, que al ser la base de datos texto sencillo puedes arreglar los desagüisados con el vi, mientras que en el caso de rpm hay que manipular una base de datos binaria con herramientas más elaboradas.

La segunda ventaja que los paquetes deb no son más que un par de tar.gz y archivos de texto en un archivador ar normal, que se pueden manipular con herramientas sencillas mientras en rpm a lo más que se llega es a leer de los paquetes vía rpm2cpio.

... Y nada más.

Por cierto, que los errores en la base de datos de Debian tipo "dejo un paquete en estado instalado y no instalado a la vez" ocurren. Yo he arreglado dos en lo que llevamos de año en lo poco que uso deb (por 0 en lo que mucho que uso rpm, si bien en rpm también los he visto, por corrupción del sistema de archivos de /var y similares).

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 :-).

En rpm sí se consideran esas cosas desde el principio AFAIK. Desconozco si en Debian esto sucede por causa de un error humano por parte del empaquetador o si por contra es una limitación de deb.

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

[ Padre ]


Por alusiones... (none / 0) (#9)
por melenas a las Mon Jul 21st, 2003 at 11:04:52 AM CET
(Información Usuario)

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 ]


Contesto la parte que me toca (none / 0) (#10)
por jorginius ("jorginius" en Google Mail) a las Mon Jul 21st, 2003 at 12:45:47 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

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


Pero no es por una limitación de rpm, que es lo que comentabas al principio.

Por cierto, has dado un salto :-). Cito:

Mientras RPM para sus dependencias se basa en archivos individuales[...]


Pero en ninguno de los ejemplos que pones hay una dependencia a un archivo suelto. Veo referencias a paquetes y referencias a sonames (no se mira si hay tal o cual biblioteca, sino si en algún paquete hay una biblioteca que provee el soname que se necesita).

Una dependencia de ese estilo, del estilo que criticabas en el post inicial, sería algo como: "/usr/lib/sendmail" o "/bin/sh" o "/sbin/install-info".

De todas formas, sigo sin ver la desventaja de indicar las dependencias como sonames (por ejemplo) en vez de como paquetes. ¿Cual es el problema que las dependencias por paquetes soluciona?.

¿Qué si tienes dependencias por paquetes puedes reemplazar los paquetes por versiones superiores sin perturbar al resto?, ¿y como lo vas a hacer si se trata de bibliotecas y el paquete superior no provee los sonames que necesitan los binarios de los paquetes antiguos?. Tampoco hay dificultad alguna de cambiar más adelante el layout de los paquetes aún con esas dependencias...

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

Yo a eso lo llamo "cómo funcionarían las cosas en un mundo ideal". Te lo repito, por si no quedó claro entre tanta demagogia: el problema es que no llega a estar "perfectamente configurado" porque le falta algo que no está listado en la lista de dependencias.

¿Cómo llamas a un paquete que te ha dejado todos los archivos colocaditos en el sistema de archivos pero que no aparece todavía en la lista de paquetes instalados? (porque el proceso de configuración falló a la mitad, con un error de perl bastante poco esclarecedor). Yo lo llamo "a medio instalar" pero quizás haya un término más técnico que los defina :-).

y si te da problemas de dependencias es por culpa de uno mismo o como dice Sinner hay algunos torpedos que no empaquetan bien.

Por culpa de uno mismo lo dudo y sobre el segundo punto sólo instalo paquetes de la rama "estable", sin hacer nada especial.

Como ya he explicado anteriormente, cuando instalas ssh, con debconf te pregunta en un perfecto español [etc,etc]

Y como ya he dicho antes, no me refiero a eso sino a que se incluya cliente y servidor en el mismo paquete. No me gusta un pelo dejar un cliente ssh en una máquina servidora (con su servidor sshd). Casi tan poco como un compilador.

Además es sólo un ejemplo. De lo más habitual son las "dependencias circulares": paquetes que dependen de paquetes que a su vez dependen de los primeros. ¿Para que los separan en paquetes independientes entonces si tantos unos como otros no se pueden instalar sin ellos?.

De todas formas, todos estos son fallos del empaquetado de Debian y no de deb en si.

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.

No creo que estemos en el mismo caso. Es salirse un poco de tema, pero a mí Debian me pareció trivial de instalar. Básicamente se trata de pulsar enter de forma compulsiva :-).

Al programa de instalación le sobra es el menú en el que puedes elegir los módulos que vas a instalar y quizás le falta (pijotada total) una opción "prefabricada" para sacar la instalación por el terminal serie, pero por lo demás está muy bien.

Los problemas vinieron después de instalar, me temo.

[ Padre ]


Respuestas (none / 0) (#11)
por melenas a las Mon Jul 21st, 2003 at 01:38:54 PM CET
(Información Usuario)

Pero en ninguno de los ejemplos que pones hay una dependencia a un archivo suelto. Veo referencias a paquetes y referencias a sonames (no se mira si hay tal o cual biblioteca, sino si en algún paquete hay una biblioteca que provee el soname que se necesita). Una dependencia de ese estilo, del estilo que criticabas en el post inicial, sería algo como: "/usr/lib/sendmail" o "/bin/sh" o "/sbin/install-info".

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

De todas formas, sigo sin ver la desventaja de indicar las dependencias como sonames (por ejemplo) en vez de como paquetes. ¿Cual es el problema que las dependencias por paquetes soluciona?.

Vaya, pues la respuesta me parece de cajón, imagínate que no tengo instalado libkdefakes.so.4, ¿en que paquete estará?, pues hay que hacer rpm -f, que no se si funcionará con paquetes no instalados, y eso teniendo en cuenta que esté en un sólo archivo ¿y si hay dos versiones con el mismo, incompatible uno con otro?que sí, que urpmi lo hace automáticamente pero no dirás que es más engorroso además de que urpmi es una aplicación externa. Sin embargo imaginemos que el mismo paquete pide kdelibs (>= 3.1.2-9.3), ¿no es más fácil pues ya te pide paquete y versión?. Y una última cosa, este ejemplo está sacado del kdebase de texstar tanto libkdefake.so.4 como kdelibs (>=3.1.2-9.3)

el problema es que no llega a estar "perfectamente configurado" porque le falta algo que no está listado en la lista de dependencias.

No sé que problema has tenido pero seguramente trataste de instalarlo con dpkg -i, te dió dependencias incorrectas y depués trataste de solucionarlo con apt-get, normalmente esas cosas se arreglan con apt-get install -f como indica claramente apt-get cuando tiene ese problema.

¿Cómo llamas a un paquete que te ha dejado todos los archivos colocaditos en el sistema de archivos pero que no aparece todavía en la lista de paquetes instalados? (porque el proceso de configuración falló a la mitad, con un error de perl bastante poco esclarecedor). Yo lo llamo "a medio instalar" pero quizás haya un término más técnico que los defina :-).

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.

Y como ya he dicho antes, no me refiero a eso sino a que se incluya cliente y servidor en el mismo paquete. No me gusta un pelo dejar un cliente ssh en una máquina servidora (con su servidor sshd).

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 ¿no?

Además es sólo un ejemplo. De lo más habitual son las "dependencias circulares": paquetes que dependen de paquetes que a su vez dependen de los primeros. ¿Para que los separan en paquetes independientes entonces si tantos unos como otros no se pueden instalar sin ellos?.

¿Habitual?, ni una sola vez me he encontrado con eso que dices, (en RPM sí, cuando instalé KDE 2 en SuSE y ví que kdebase dependía de arts y arts de kdebase con lo cual tuve que hacer un rpm --nodeps) a menos que uses fuentes "extrañas", de todas formas yo también las utilizo tanto en mis sistemas de escritorio (KDE 3.2 CVS) como en servidores (qmail y tynidns) y NUNCA me he encontrado con eso, y ese es un problema que un empaquetador chapuzas también puede hacer en RPM como explico antes

Al programa de instalación le sobra es el menú en el que puedes elegir los módulos que vas a instalar y quizás le falta (pijotada total) una opción "prefabricada" para sacar la instalación por el terminal serie, pero por lo demás está muy bien.

Ahí estamos de acuerdo ;-), la instalación de Debian en un principio es poco intuitiva, además de elegir módulos a mano, pero créeme cuando te digo que yo también trabajé con rpm y al principio de usar los deb me cagué en todos los rijostrios de quien los inventó (los deb digo), pero en cuanto le cogí el tranquillo y ví que había formas de arreglar los fallos más finas que rpm --nodeps, pues que me enamoré de él. (de los deb, no de quien lo inventó XDD)


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 ]


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 ]


 
Melenas, que tu ceguera te pierde (none / 0) (#16)
por sinner a las Mon Jul 21st, 2003 at 10:04:48 PM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Melenas, famo a ve. Tranquilizate. Que nadie dice que te cambies a Mandrake (de momento).

Las capacidades de .rpm y .deb son muy similares. La capacidad de torpedismo de los empaquetadores es alta, siendo el % de torpedos igual en ambos paquetes. Pero como hay mas .rpms que .debs disponibles en la red, el numero de finstros sessualers de paquetes .rpms es mas alto que el de .debs.... sencillamente por que hay mas .rpms.

Luego.... permiteme que te destruya un mito.


Melenas, repite con Sinner:

"apt-get es package-agnostic".


Todo lo que puedas hacer con apt-get en tu Debian, lo puedo hacer yo (o Jorginius) en mi (su) Red Hat.

Esta ultima parte se carga el 40% de la dicusion (casi de besugos, p.q. ambos decis lo mismo una y otra vez y no os leeis o no entendeis las respuestas del otro).

Depues, las herramientas mas basicas (rpm , dkpg)... rpm es mas capaz que dkpg.

Y, para acabar: en urpmi puedes poner nombres de paquete, ficheros, sonames o partes del nombre de un paquete.

Y, en definitiva, en Mandrake dispongo de /usr/bin/rpm , /usr/bin/urpmi y /usr/bin/apt-get , mientras en Debian unicamente dispones de /usr/bin/apt-get y /usr/bin/dkpg (o como se escriba)


Posdata: que tiene que ver todo esto con la entrada original del diario?


Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Asi me gusta, afirmaciones con datos :) (none / 0) (#17)
por iarenaza a las Mon Jul 21st, 2003 at 11:32:56 PM CET
(Información Usuario) http://www.escomposlinux.org/

Depues, las herramientas mas basicas (rpm , dkpg)... rpm es mas capaz que dkpg.
No es que yo diga lo contario, pero... ¿no estaría bien basar la afirmación anterior en algún tipo de dato objetivo verificable? Ya sabes, por aquello de dar buena imagen y tal... :-P

Saludos. Iñaki.

[ Padre ]


 
2 contra 1 @#\|!" para cada uno XDD (none / 0) (#18)
por melenas a las Tue Jul 22nd, 2003 at 12:23:08 AM CET
(Información Usuario)

Esta vez voy a pasar de comentarios sobre "a mí me funciona bien y lo otro me cascó", pasaré a los hechos puros y duros, y si me equivoco que se me corrija, en fin allá vamos:

Campos de RPM
  • Depends: Lo tiene rpm
  • Recommends: Dependencias que ignorarán dpkg y apt-get pero no select, no lo veo en RPM
  • Suggest: NO está en rpm
  • Pre-Depends: En rpm es por defecto
  • Conflicts: Lo tiene rpm
  • Provides: Lo tiene rpm
  • Replaces: NO está en rpm, aunque se puede sustituir por Conflicts


Programas para control
  • apt-get: urpmi
  • dpkg: rpm
  • dpkg-awk: ???
  • dselect,aptitude: ???
  • kpackage, synaptic: mandrakerpm, quizás lo único que encuentro muy superior
  • jablicator: kickstart
  • debconf: ???
  • apt-cache: ¿urpmf? muy limitado
  • deborphan: ¿rpmorfhan? descontinuado
  • apt-spy: ???Calcula el server más rápido
  • apt-src,apt-build:???Construye paquete en demanda, no tan potente como Gentoo...


Se podría decir que claro, como rpm es tan bueno no necesita de tantas herramientas, ¿entonces por qué se creó urpmi?¿o apt-rpm?¿o up2date? y aunque es un buen principio, aún le falta mucho para alcanzar al conjunto de herramientas de debian.

Otra cosa es que mucha gente se pasa de rpm a deb (yo por ejemplo), sin embargo del caso contrario no conozco ninguno, como tampoco de nadie que se pasa de Linux a Windows ;-P

En fin los datos de los empaquetamientos los he sacado de http://www.linux-mandrake.com/howtos/mdk-rpm/ y de http://www.debian.org/doc/manuals/maint-guide/index.es.html#contents, pero seguro que alguien con más experiencia os podría contar otras cosas, ya que yo sólo llevo 9 meses con Debian en serio y 6 como mi principal distribución.

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 ]


 
Estoy de acuerdo (3.00 / 1) (#6)
por suy (suy21.existe-en.lycos.es) a las Mon Jul 21st, 2003 at 01:41:55 AM CET
(Información Usuario) http://lacurva.net/

Yo hoy he estado probando, en un ordenador que tengo para hacerle putaditas, un hasefroch XP y una MKD 9.1. Si no fuera por falta de tiempo, haría una comparativa entre ambos, ya que resulta muy interesante. Si finalmente puedo, os lo haré saber.

La sensación que me ha dejado mandrake, es muy muy buena. El tema galaxy está bastante majo, la instalación ha sido espectacularmente fácil (yo hubiera preferido algo menos automatizado, pero desde mi punto de vista, el nivel al que se pone, es perfecto para el usuario al que va dirigido mayormente), las fuentes están muy bien configuradas, y el GIMP puedo usarlo sin miedo a usar unas fuentes horribles (con Debian woody, solo tengo bien configuradas las fuentes de KDE).

Sin embargo, hasta la fecha, me sigo quedando con Debian. El software a la última puede estar bien para un escritorio, pero no es lo más apropiado para otros ámbitos. Además, los paquetes debian para mí han sido ver la luz. El empaquetado que tiene esta distribución, es difícil de superar ahora por ahora.


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere
[ Padre ]


Instalación (none / 0) (#7)
por sinner a las Mon Jul 21st, 2003 at 05:02:21 AM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Si, cuando te enseña la primera pantalla que dice "Pulse F1 para ayuda o más opciones / Enter para empezar la instalacion" pulsas F1, verás que puedes elegir la instalación en modo experta, donde te pregunta hasta el tamaño del bañador que quieres en el fondo de pantalla de la Txell. Bueno, casi :)

No eres el único al que se le pasa por alto este "feature".

Por ejemplo, a mi jefe también le ha pasado, cuando le estaba metiendo MDK 9.1 a su madre (una señora que es abuela con, al menos, 3 nietos). Y, claro, em ha llamado diciendo eso de "No puéh seeeeeeeeer! Dimisión! ¿Andestá la instalación avanzada?"

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.



Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


No me expliqué bien (none / 0) (#13)
por suy (suy21.existe-en.lycos.es) a las Mon Jul 21st, 2003 at 04:13:10 PM CET
(Información Usuario) http://lacurva.net/

No eres el único al que se le pasa por alto este "feature".

No, no se me pasó por alto :-), tan solo que en la comparativa, quería comparar un Hasefroch con una mandrake, y ver si realmente queda algún resto del mito "es difícil de instalar". De hecho, como casi todas las distros, traía varios métodos; que recuerde, el normal, el experto, vgalo, y puede que alguno más.

Por cierto, un dato curioso del hasefroch, es que se instaló en unas dos gigas de espacio, sin dejarme eliminar ningún software por defecto. Mandrake se instaló en la birria de espacio que dejó libre, y con el kde casi entero (lástima que había poco, quería probar GNOME y otras cosas nuevas también).


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere
[ Padre ]


 
Tú lo has dicho (none / 0) (#3)
por trinux a las Sun Jul 20th, 2003 at 04:27:51 PM CET
(Información Usuario) http://solognu.wordpress.com/

¡¡AMEN!! XD

[ Padre ]


 
Ése sí que es bueno (none / 0) (#4)
por man ls a las Mon Jul 21st, 2003 at 12:17:08 AM CET
(Información Usuario)

Me parece excelente, a ver si me animo y creo un usuario
dpkg-awk -f /var/lib/dpkg/available 'Depends:.*kdelibs4.*' | egrep Package: | cut -d \ -f2 | xargs apt-get install -s
para sustituir al mío, que la página de man ls me la sé ya de memoria.

8^)

[ Padre ]


 
sin exagerar ;) (none / 0) (#8)
por dodger (dodgerNOSPAM@NOSPAMseastorm.org) a las Mon Jul 21st, 2003 at 09:21:36 AM CET
(Información Usuario) http://www.seastorm.org

>Al final acabareis todos con Mandrake, ya lo veo. Esto es el principio.

>MWAHAHAHAHAHA

Bueno, bueno, no exageres... Aunque me ha gustado mucho lo poquito que he tardado/trabajado para tener la mandrake funcionando estupendamente, y hoy por hoy sería la distro que aconsejaría a cualquier nuevo linuxero, como dicen por ahí "debian es debian". Es un tema de optimización, más que nada. Seguro que uno también puede currarselo con mandrake, pero la filosofía es distinta: con debian, no tengo un byte ocupado que no sea útil, y en mandrake tengo ahí (por ejemplo) los modulos del ratón usb al acecho. Más cómodo, pero innecesario gran parte de las veces.
Aunque reconozco que con los bichos de hoy en día, tampoco es necesario exagerar con la optimización... Pero nadie puede llamarse hombre si no ha instalado una debian ;)

--
dodger
http://www.seastorm.org
"Hacer software basado en requisitos es igual que caminar sobre el agua: Es fácil, si están congelados"
[ Padre ]


 
urpmi mola | 18 comentarios (18 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

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