Este artículo formaba parte del que se publicó en el número 63 de la revista MundoLinux. De nuevo el copyright es mío, y no puedo aún autorizar su reproducción total o parcial, modificación o redistribución sin mi autorización expresa o del editor de la revista.
La idea es conseguir que todo se convierta en un documento con algún tipo de licencia libre cuanto antes. Mientras tanto ahí está.
Está basado fundamentalmente en una actualización de versión de 9.1 a 9.2 de Mandrakelinux, pero los consejos que se dan en él pueden ser aplicados a cualquier cambio de versión. Por ejemplo un cambio de la 10.0 a 10.1 (que será liberada en menos de un mes para el público en general). Al final del documento señalo qué cambia para versiones posteriores de Mandrakelinux en el proceso de migración.
Espero que os sea de alguna utilidad :)
Actualizando el sistema
Hasta ahora no habíamos evaluado la opción de actualizar un sistema ya instalado. Teniendo en cuenta que llevamos ya más de un año de sección, es más que probable que los lectores habituales de la misma tengan ya una versión anterior de la distribución instalada. No solo eso, sino que además dicha instalación se encontrará configurada al gusto y con las necesidades del usuario cubiertas.
Sin embargo también tenemos el problema del tiempo de vida de los productos. Todas las versiones anteriores a la 9.0 ya han excedido el suyo y carecen de las necesarias actualizaciones de seguridad. Y la versión 9.0 sólo posee actualizaciones de la base del sistema hasta marzo del 2004 (mirar el cuadro 1 de enlaces para obtener más información). Desde ese punto de vista cualquier usuario con una distribución que ha excedido o está a punto de exceder su tiempo de vida, debería plantearse seriamente la migración.
Pero, ¿puede plantearse una migración que no conlleve excesivos quebraderos de cabeza? Eso es lo que hemos querido probar para este artículo. Y para ello los objetivos que nos planteamos fueron conservar en la medida de lo posible la misma configuración y datos del sistema. Los resultados obtenidos han sido variables, pero la conclusión es que es posible la migración aunque no esté exenta de problemas.
El primer paso que debemos dar es leer la página de erratas de Mandrake 9.2 (ver cuadro 1). Lo más importante sobretodo es el apartado de los problemas surgidos con los lectores de CDs LG. Hagamos como hagamos la instalación debemos tener en cuenta ese problema, que afortunadamente tiene su solución adjunta en dicho enlace.
Una vez que hemos comprobado dicha página procederemos a otro paso muy importante. Hacer un volcado de seguridad del sistema. Hay que tener en cuenta que todo puede fallar en esta vida, y en nuestra mano está que tenga una solución sencilla o no. Los datos más sensibles suelen encontrarse en los directorios /etc (donde está todos los archivos de configuración del sistema) y /home (que contiene quizás lo más importante en un sistema de escritorio, las cuentas de usuario).
A continuación hay otra cosa por hacer previa a la instalación. No es algo imprescindible pero sí recomendable puesto que podría dar algún problema posteriormente. Se trata de eliminar todas las fuentes de software configuradas para el sistema. Esto puede realizarse fácilmente como administrador del sistema y tecleando en una consola el comando urpmi.removemedia -a. Después, otro paso recomendable es volcar la lista de paquetes instalados a un fichero de texto, de forma que más tarde podamos saber qué paquetes se han actualizado y cuales no. Ejecutamos el comando rmp -qa | sort > paquetes-antiguos.txt .
Tras estos cuatro primeros pasos podemos proceder a la actualización de nuestro sistema ¿Qué opciones hemos considerado? Básicamente dos.
Primer método de actualización (1)
La primera es la más sencilla aunque no la más eficiente. Si tenemos los CDs de la versión 9.2 reiniciamos el PC y comenzamos la instalación como haríamos para instalar por primera vez el sistema. En uno de los pasos intermedios del proceso, antes de la elección de las particiones a usar, el instalador detectará qué sistemas tenemos instalados en el disco duro. En caso de detectar alguna versión de Mandrake (en nuestras pruebas nunca ha fallado) nos ofrecerá las opciones de instalar un nuevo sistema Mandrake 9.2, o bien actualizar alguno de los existentes. Escogeremos la opción de actualización sobre el sistema que deseemos, y a partir de ese momento el proceso de actualización es automático.
Al terminar sería recomendable configurar una fuente de updates y realizar las actualizaciones de seguridad y de fallos correspondientes.
Si en nuestra versión anterior de Mandrake usábamos fuentes alternativas de software como Contrib y PLF, deberíamos ahora configurar dichas fuentes. Una forma sencilla es acudir a la web de Easy Urpmi Config y seguir las instrucciones de configuración que en ella se detallan (el enlace en el cuadro 1).
Una vez configuradas y si teníamos software instalado desde dichas fuentes, procederemos a la actualización de dichos programas o paquetes (si es que poseen versiones actualizadas). Para comprobar que no surgirán problemas, desde una consola de texto y como administrador del sistema teclearemos urpmi --test --auto-select --media contrib plf. Si este comando finaliza con éxito entonces podremos ya invocar el comando urpmi --auto-select --media contrib plf que realizará la actualización.
Segundo método de actualización (2)
El segundo método alternativo requiere de una buena conexión de red, tener un mirror local de la versión actual de Mandrake, o bien cargarse de paciencia. Pero se trata del método que mejor resultado nos ha dado. Consiste en definir como una fuente software, cualquiera de los mirrors disponibles de la versión actual de la distribución (la fuente main). Además, añadiremos la fuente de actualizaciones updates. Y Si hemos usado en la versión instalada las fuentes de Contrib y PLF también las configuraremos (de nuevo es sencillo realizar todos estos pasos con la ayuda de Easy Urpmi Config).
Es recomendable que en este momento, si se usa el modo gráfico se abandone y se pase a una consola de texto. Una forma sencilla es cerrar la sesión gráfica actual, pulsar las teclas CTRL-ALT-F1 simultáneamente, iniciar sesión como administrador de sistema y ejecutar telinit 3. Seguimos como administrador del sistema, y el paso a dar ahora es actualizar de forma independiente la propia herramienta URPMI. Ejecutamos urpmi urpmi. De esta forma evitaremos los problemas de las versiones anteriores y disfrutaremos de algunas nuevas características.
Algo que puede dar problemas de forma aleatoria son las claves de las firmas de los paquetes. En alguna de las instalaciones que hemos realizado urpmi insistía en que los paquetes de algunas fuentes carecían de firma válida. Para evitar este problema, importaremos a mano las firmas de cada una de las fuentes instaladas. Primero borraremos el archivo /var/lib/rpm/PubKeys . Para main y contrib las firmas se encuentran en el directorio de cualquier mirror mandrake/9.2/i586/Mandrake/base y se corresponden con los archivos pubkey y pubkey2. Se copian dichos archivos a nuestro sistema, y desde el mismo directorio donde estén se ejecuta en una consola de texto rpm --import pubkey pubkey2 . Para updates se procede de la misma forma con el archivo mandrake/updates/9.2/base/pubkey . Y para plf se descarga el archivo de firmas desde su web y se instala igual que las anteriores. Hay que tener en cuenta que en la fuente contrib hay muchos paquetes que no son producidos por Mandrake y cuyas firmas no coinciden por tanto con las instaladas. Si se instalara alguno de esos paquetes se producirá el aviso de firma no válida. El obtener dichas firmas queda fuera del objetivo de este artículo.
Llega el momento más delicado. La actualización en sí. En primer lugar comprobaremos que el proceso no dará problemas con el comando urpmi --test --auto-select --media main contrib updates plf. Si el resultado es correcto puede entonces pasarse a ejecutar urpmi --auto-select --media main contrib updates plf.
Una vez terminado el proceso, que con una conexión ADSL básica y partiendo de una Mandrake 9.1 con mucho software instalado duró más de cinco horas, podremos decir que tenemos nuestro sistema casi completamente actualizado a la última versión.
Pero antes de reiniciar y comprobar los cambios...
Problemas que pueden surgir tras la actualización
Una vez que comencemos a manejar el sistema podemos encontrarnos con diversos problemas. Nosotros hemos detectado los siguientes (entre paréntesis se indica para qué método puede surgir el problema):
(1) En la instalación desde CDs en modo texto no se da la opción de actualización del sistema. Sólo eso posible instalar un sistema nuevo.
(1,2) Algunos paquetes de KDE han sido divididos en subpaquetes debido a que instalaban muchos programas a veces no requeridos por el usuario. Esto implica que los que sí son habitualmente usados también hayan desaparecido. En KDE seguramente nos faltarán por ejemplo Kmail, Konsole, Kget, etc. Para recuperarlos podremos usar el rpmdrake buscando por el nombre de esos programas los paquetes que los incluyen para instalarlos.
(1,2) Si hubiéramos instalado programas que pertenecieran a alguna fuente de software no descrita aquí, pudiera surgir algún conflicto de versión o bien no actualizar dicho programa y que el mismo dejara de funcionar. Nosotros tuvimos dicho problema con el programa Evolution, instalado desde la fuente texstar que para esta nueva versión de Mandake no existe. La solución en estos casos es detectar dicho software, desinstalarlo junto con sus dependencias, y reinstalarlo posteriormente pero desde alguna de las fuentes descritas anteriormente.
(2) También pueden surgir problemas de versiones entre los paquetes de plf y el resto de fuentes. Si no queremos que esto ocurra podremos optar por no configurar esta fuente inicialmente, actualizar el sistema, y tras ello configurar la fuente e instalar los paquetes que deseemos de la misma.
(1,2) Para conocer con más precisión qué se ha instalado o actualizado y qué no, volcaremos la nueva lista de paquetes en otro fichero rpm -qa | sort > paquetes-nuevos.txt . Ahora realizaremos una comparación con el archivo generado al principio de la instalación comm -1 -2 paquetes-antiguos.txt paquetes-nuevos.txt > paquetes-no-actualizados.txt . Analizando el nuevo fichero obtenido observaremos tres posibilidades: que un paquete no se haya actualizado porque no tiene actualización disponible, porque ha dejado de existir o porque urpmi no ha sido capaz de localizar la nueva versión. El último caso se produce cuando el paquete con la nueva versión del programa tiene un nombre distinto al paquete instalado.
(2) Uno de los programas no actualizados, por cambio de nombre en el paquete, probablemente será el kernel de la nueva distribución. Es por tanto recomendable instalar el paquete del kernel que pertenecerá a la fuente updates.
(1,2) Puesto que la versión Download Edition ni ninguna de las fuentes nombradas tiene en principio paquetes con drivers propietarios (como hay para algunas tarjetas gráficas ATI y NVIDIA), es recomendable, antes de actualizar el sistema, desinstalarlos puesto que es muy probable que no funcionen con la nueva versión del kernel y necesiten de una reinstalación posterior.
(2) Si encontramos que los comandos urpmi de actualización fallan con frecuencia en las descargas, podemos probar de nuevo añadiendo la siguiente opción --wget.
Pruebas realizadas
Por supuesto la descripción de este proceso viene de una serie de pruebas experimentales realizadas por al autor. Las pruebas han consistido en actualizar a Mandrake 9.2 Download Edition los siguientes sistemas instalados todos desde CDs:
Consejos para instalar de cero y facilitar la actualización
Hemos visto que la actualización de la distribución a una nueva versión no es trivial. Pero si instalamos y mantenemos nuestro sistema con los consejos que expondremos a continuación, será más sencillo realizar dicho proceso. Para ello decidimos que el primer paso es instalar de cero el sistema. Independientemente del método escogido (instalación via CDs, red, etc), estas son nuestras recomendaciones (ojo, hablamos de entornos de escritorio):
Cuadro 1 Bibliografía y Enlaces
Página de erratas de Mandrake 9.2
http://www.mandrakelinux.com/en/errata.php3
Easy Urpmi Config
http://plf.zarb.org/~nanardon/
Artículos de actualización de Mandrake
http://mandrake.vmlinuz.ca/bin/view/Main/UrpmiUpgradeIssues
http://libertonia.escomposlinux.org/story/2003/11/3/02824/2638
Artículos muy interesantes para pasar de Debian a Mandrake
http://libertonia.escomposlinux.org/story/2003/11/12/13748/839
http://libertonia.escomposlinux.org/story/2003/11/13/18617/519
Tiempo de vida de las versiones de Mandrake
http://www.mandrakesecure.net/en/productlifetime.php
Mirrors de Mandrake
http://www.mandrakelinux.com/en/ftp.php3
Cambios en el proceso a tener en cuenta para versiones posteriores de Mandrakelinux
Voy a contar mi experiencia personal actualizando tres PC con Mandrake 9.2 a la versión 10.0 con urpmi.
Existen documentos por ahí que explicam como se hace, pero aveces la realidad es otra y no todo es tan facil.
Primero consigo todos los paquetes base (3171 paquetes, 2.8G) de un servidor ftp y tambien los updates y lo guardo todo en una partición del disco duro expresa para esto.
De momento paso de los contrib y de plf.
Paquetes base:
ftp://ftp.rediris.es/pub/Linux/distributions/mandrakelinux/official/10.0...
Updates:
ftp://ftp.rediris.es/pub/Linux/distributions/mandrakelinux/official/upda...
Que no se diga que no pongo de donde saco los paquestes !!!
Seguidamente entro en el centro de control mandrake y borro las fuentes antiguas y añado las nuevas (base y updates). Esto se puede hacer desde consola pero teniendo un linux funcionando no me voy a matar a teclear ;-)
Por cierto, yo nunca me bajo los hdlist, dejo que mandrake se los cree a partir de los paquetes que encuentra, si hay alguno chungo se va a quejar y no te va a dejar añadir la fuente.
Desinstala todo lo desinstalable, tendras menos problemas (juegos, etc ...)
Si todo es correcto abro una consola no grafica como root y empieza el espectaculo ...
# urpmi --test -v --no-verify-rpm urpmi : esto testea si es posible actualizar el instalador, normalmente acaba con un reconfortante “La instalación és posible”, si se queja de algun paquete instalado pues lo quito con kpackage y ya está. En mi caso sin problemas en los tres PC.
# urpmi --test -v --no-verify-rpm --auto-select : testea si es posible actualizar todo el sistema, aquí suelen salir problemas con algunos paquetes KDE que se tienen que desinstalar. En mi caso los paquetes problematicos no han sido los mismos en los tres PC. Desinstalo los paquetes molestos y consigo el mensaje “La instalación es posible”.
Genial, salgo del escritorio y ..
# init 3 : no es necesario pero lo suelo hacer.
# urpmi -v --no-verify-rpm urpmi : Llega el momento de la verdad, parece que todo funciona pero falla a mitad de instalación quejandose de unos paquetes que no han podido actualizarse por culpa de “otros” ... ni caso, le vuelvo a meter
# urpmi -v --no-verify-rpm urpmi : En dos de los PC la segunda vez no se queja (??¿¿) y actualiza, en el tercero pues continua sin actualizar , ala, a quitar los paquetes “culpables” pero claro, ya estoy en consola y esto ya no es tan facil
# man rpm : A mirar el manual ;-)
# rpm -e “el paquete molesto”
Y a probar otra vez
# urpmi -v --no-verify-rpm urpmi ..... repetir el proceso anterior hasta conseguir actualizar urpmi.
Seguidamente a por el resto del sistema:
# urpmi -v –no-verify-rpm –auto-select : Si hay suerte se actualiza todo pero no, aqui tambien falla y se tiene que seguir el procedimiento anterior, normalmente le meto
# urpmi -v –no-verify-rpm –auto-select otra vez y se actualizan unos cuantos paquetes mas, pero llega un punto en que solo da un inmenso error (pantallas y pantallas), presta atención para ver que paquete es el primer culpable del error y lo desinstalas com rpm -e “paquete” y repetir el proceso hasta conseguir un mensaje “Ya está todo instalado”.
Cruzas los dedos y le metes un
# init 0 y arrancas el PC.
Ya tienes el sistema “casi” actualizado, pero sorpresa, ha desaparecido el centro de control mandrake !!!, no problem, entras en consola y como root tecleas
# urpmi -v drak y te saldra una lista de paquetes de mandrake, instalas drakconf, drakxtools, hardrake, etc ... y ya está todo en su sitio.
Seguidamente entras en el centro de control y acabas de instalar los paquetes que falten y actualizas el kernel de la forma habitual.
Añades los contrib y plf y los actualizas tambien.
Con kpackage vas mirando si han quedado paquetes antiguos (en mi caso kmail 3.1) mirando la fecha de instalación y los quitas (atención, algunos paquetes no se han actualizado ya que la version es la misma en mandrake 9.2 y 10.0), es un poco palo pero se mantiene el sistema limpio.
Tengo la mania de correr los asistentes de mandrake (hardrake, etc...) para regenerar los archivos de configuración.
En los tres PC al final de todo el proceso me ha quedado un Mandrake 10.0 perfectamente instalado.
Espero que el escrito sea de ayuda.
ticiajosep
PD: Se aceptan todo tipo de correcciones, sugerencias, etc ...
(Aviso para navegantes: ladrillo :P)
Aprovechando que tenía unos días libres, decidí actualizarme de una vez de Mandriva 2006 a 2007. El modo de actualización que escogí fue utilizando urpmi.
Dado que tengo que hacer actualizaciones de más equipos que el mío, escribí un pequeño resumen de los pasos que iba dando para tenerlos en cuenta a la hora de actualizar los demás equipos. Aquí dejo dicho resumen por si a alguien le fuese de alguna utilidad. Nótese que esto no es un manual ni nada similar, para eso ya está Actualizar Mandrakelinux de una versión previa a una nueva.
Debe notarse también que si alguien está pensando en actualizarse de este modo y todo este tocho le da miedo, no debe asustarse. Por un lado yo soy muy tiquismiquis con las actualizaciones, y por otro había tocado cosas en el sistema que, de usar una Mandriva pura y dura (vamos, sin andar toqueteando ficheros de configuración del sistema, instalando software desde código fuente y demás) no habrían sido problema. Y además, siempre me enrollo como una persiana a la hora de contar cosas que podrían llevar mucho menos espacio :)
Antes de empezar (o más adelante al encontrar un problema), es recomendable ojear las notas de publicación (en inglés) y las erratas de la nueva versión.
Lo primero de todo es realizar la actualización en sí del sistema. Eliminé todos los repositorios utilizando urpmi.removemedia -a, y añadí los de la 2007 para x86 mediante Easy Urpmi. Para empezar, únicamente añadí main, main_updates, contrib y contrib_updates. No añadí ninguno de PLF ni backports porque primero quería actualizar puramente la distribución, y luego ya pondría los añadidos.
Una vez añadidos los nuevos repositorios, me pasé a una consola en nivel de ejecución 3 (Ctrl+Alt+F1, entrar como root y ejecutar telinit 3) y actualicé el sistema mediante urpmi --auto-select. Algunos paquetes no se podían instalar, y otros tenían que desinstalarse para proceder con la actualización, así que tomé nota de ellos.
Se puso a instalar y al terminar, hubo una serie de paquetes que no fue capaz de instalar debido a colisiones con antiguos paquetes. Por un lado, con los paquetes de OpenOffice.org 1.1.5 de la 2006, así como los de la 2, estos últimos habiendo sido instalados sin usar los repositorios oficiales de la 2006. Eliminé los paquetes problemáticos y volví a ejecutar urpmi --auto-select, instalándose ahora perfectamente los que faltaban relacionados con este problema.
Pero también había otro problema, y era que KDE no podía actualizarse debido a lo siguiente:
instalando mandriva-kde-config-common-2007-28mdv2007.0.noarch.rpm desde
/var/cache/urpmi/rpms
Preparando... #############################################
Installation failed:
file /usr/share/sounds/mdv-startup.wav from install of
mandriva-kde-config-common-2007-28mdv2007.0 conflicts with file from package
mandriva-kde-config-file-2006-10mdk
Para solucinar esto, primero desinstalé manualmente mediante rpm el paquete mandriva-kde-config-file (rpm -e --nodeps mandriva-kde-config-file-2006-10mdk) y luego instalé mediante urpmi su sustituto (urpmi mandriva-kde-config-common-2007-28mdv2007.0), para a continuación terminar la actualización (urpmi --auto-select).
Para terminar con la actualización, ejecuté urpmi kernel, seleccioné el que me convenía, y luego instalé los fuentes con urpmi kernel-source. Ahora, toca reiniciar.
Excelente, arranca ;) Entro en mi usuario y parece que todo está más o menos en su sitio. Ahora bien, las fuentes no están tan nítidas como deberían, y son demasiado pequeñas. El menú de KDE tiene alguna cosa mal, y faltan algunos iconos en kicker. KDE se queja de que no puede conectar con DCOP (lógico, ya que en esta versión DCOP se aparcó en favor de DBUS, por lo que será un mero problema de configuración). No tengo sonido, y el icono de dispositivos del escritorio no funciona, ya que dice que el protocolo "device" no está soportado. A primera vista, no hay nada más mal.
El problema del sonido tiene fácil solución. Es un bug (reportado hace tiempo, aunque aún sin solucionar del todo) debido al cuál eliminaron el controlador OSS de la tarjeta de sonido en el kernel, por lo que hay que utilizar ALSA. Simplemente abrí HardDrake, cambié del controlador OSS al de ALSA y listo. Luego utilizando KMix puse el volumen a mi gusto y problema solucionado.
Los iconos de kicker también se puede solucionar fácilmente simplemente añadiendo los que faltan mediante la opción "Añadir aplicación al panel".
En cuanto al problema del icono de dispositivos, voy a sus Propiedades, pestaña Aplicación. Ahí indica el comando que ejecuta el icono. Sustituyo "device:/" por "media:/" en dicho comando, pues el primer protocolo era el que se utilizaba en la versión de KDE de Mandriva 2006, pero que ya no existe en ésta, sino que se utiliza el segundo. Problema solucionado, ya muestra los dispositivos como antes. Aunque dado que, al fin, vuelve a funcionar la opción de mostrar los dispositivos montados en el propio escritorio, la ventana de dispositivos para mí ya no tiene mucha utilidad :)
Vamos ahora con el problema de las fuentes. En lo que respecta a la nitidez, simplemente fui al centro de control de KDE, sección Aspecto y temas->Fuentes, y en la configuración de "anti-aliasing" seleccioné "Estilo de pista: Completa". En cuanto al tamaño, realmente no era problema del ordenador, sino mío :) Como llevaba unas cuántas horas viendo las fuentes en consola y tengo las fuentes del servidor X a 75dpi, las veía demasiado pequeñas :P Me di cuenta al aumentar el tamaño de las mismas y ver que aquello cuadraba incluso menos que cuando estaban en pequeño ;)
Queda solucionar el problema del menú y el de DCOP. Creo un nuevo usuario y compruebo si ambos problemas existen en dicho usuario. El del menú sí, y el de con DCOP, en contra de lo que me esperaba, también. Ataquemos primero a DCOP ;)
Tras indagar por San Google, el problema parece provenir de KDESVN, un cliente de SVN en KDE. El bug es el siguiente: Couldn't connect DCOP signal. Won't receive any status notifications!. Y es un bug no reproducible, es decir, a veces pasa, a veces no, por lo que es muy divertido intentar buscarle solución :P Eliminé el servicio de menú para Konqueror de SVN para comprobar si el problema iba por ahí. En principio lo podré saber si en unos días no me volvió a dar más problemas ;)
En cuanto al menú, falta la entrada de Personal, hay una serie de entradas que no siguen la estructura de menús de Mandriva (que es la que utilizo), y otras no se muestran. Lo de la entrada de Personal, es un bug: Cannot add "Home" icon to K-panel since K-menu does not have "Home" icon any more
Lo de las entradas que no siguen la estructura de Mandriva, algunos son paquetes instalados de Mandriva, por lo que en esos casos es un bug del paquete (como en Khttrack: Missed category in desktop file). Otros, fueron paquetes instalados de código fuente.
Por lo que sé, las entradas de los menús se obtienen a partir de los ficheros desktop instalados en determinadas ubicaciones. Según la sección sobre el sistema de menús XDG del wiki de Mandriva, los ficheros desktop se buscan en los subdirectorios de XDG_DATA_DIRS/applications. Ahora bien, yo no tengo esa variable de entorno establecida, por lo que supongo que utilizará las rutas por defecto, que la experiencia me muestra que son, al menos, /usr y /usr/local/. Al estar usando KDE, además de en los directorios de datos de XDG, parece ser que los ficheros desktop se buscan también en KDEDIRS/share/applnk.
El fichero desktop, entre otras cosas, incluye las categorías a las que pertenece el paquete, lo que indica dónde se incluirá la entrada en el menú. Si el fichero desktop está instalado en algún subdirectorio de KDEDIRS/share/applnk y no incluye la entrada "Categories", en el menú aparecerá una nueva categoría llamada como el subdirectorio de applnk en que está el fichero desktop, y dentro de esa categoría una entrada para dicho fichero.
No afirmo, pero en principio que los ficheros desktop se instalen en applnk en lugar de en el directorio de XDG puede considerarse un bug del paquete, y lo mejor es informar de él. Así mismo, el hecho de que no incluyan una categoría en el archivo desktop también puede considerarse un bug. Y mientras el bug se soluciona, la mejor opción es añadir manualmente la categoría al archivo desktop por nosotros mismos. Aquí se pueden ver las categorías de Mandriva y utilizar la que más se ajuste al paquete en cuestión.
Por otra parte, están los paquetes que deberían mostrarse en el menú, pero no lo hacen. Si el paquete instala un fichero desktop en XDG_DATA_DIRS/applications o subdirectorios, debería aparecer una entrada en alguna parte del menú. Los motivos para que no aparezcan pueden ser:
En ese último caso, podría ser un "bug" de Mandriva o del paquete. ¿Por qué lo pongo entre comillas? Porque la especificación de XDG aún no es definitiva y hay algunas cosas que deben pulirse un poco aún, como las categorías y sus nombres. Así pues, hay algunas categorías de XDG que en Mandriva aún no están soportadas, y esto es deliberado, como puede verse en este bug: applications.menu lacks freedesktop.org categories.
Por otra parte, las categorías que incluye el fichero desktop podría ser que no pertenezcan a las categorías de XDG, por lo que estaríamos en este caso ante un bug del paquete.
Y ya que estamos, me decido a arreglar una cosa curiosa que me pasaba en la 2006: el lateral del menú de KDE tiene el texto de la Powerpack+, cuando yo utilizo la free. Así que hecho un ojo a los paquetes instalados cuyo nombre tengan powerpack en el nombre mediante rpm -qa --nosignature | grep powerpack y me muestra el paquete powerpackplus-kde-config.
Intento desinstalarlo, pero intenta quitar todo KDE, así que hecho un ojo a las dependencias que muestra para justificar la desinstalación (urpme powerpackplus-kde-config > powerpack, de forma que la salida se redirige al archivo powerpack, que abierto con un editor de textos se puede consultar más fácilmente que en consola).
La palabra powerpack no aparece en ningún sitio, pero sí kde-config. Compruebo si hay más paquetes llamados kde-config mediante urpmq -y kde-config, y me muestra una lista entre los que se encuentra free-kde-config. Una vez instalado este paquete, ya puedo desinstalar sin problemas el de powerpack.
Todos estos ajustes fueron hechos a nivel de usuario. Como es lógico, también hay que comprobar que, a nivel de sistema, las cosas funcionan como deben.
Al apagar el sistema, me doy cuenta de que se queda en "System halted" y no hace nada más. Simplemente habilito ACPI desde el centro de control, sección Arranque->Configurar cómo arranca el sistema y problema arreglado.
Cuando se instala un paquete mediante urpmi y dicho paquete contiene ficheros de configuración del sistema ya existentes y que fueron modificados tras su instalación, los ficheros de configuración se dejan intactos, y el fichero de configuración del paquete se crea utilizando el sufijo .rpmnew. En caso de que se desinstale un paquete que contiene un fichero de configuración modificado, dicho fichero se renombra con el sufijo .rpmsave.
Dado que la actualización fue de todo el sistema, es de esperar que existan ficheros de configuración del sistema que hayan sufrido alguno de los dos casos expuestos, por lo que se buscan los diversos ficheros en /etc cuyo nombre termine en rpmnew y en rpmsave (haciéndolo desde consola, el primer caso sería find /etc -iname "*.rpmnew").
Y ahora, se va echando un ojo a cada fichero de configuración y decidiendo qué hacer con ellos: usar el nuevo, o añadir al viejo los cambios que se incluyen en el nuevo. El comando diff, que muestra las diferencias entre los dos archivos que se le indique, es muy útil en estos casos.
Y, como siempre, hay que hacer una copia de seguridad de los archivos que se eliminen, sustituyan o modifiquen, incluso si crees que no va a pasar nada, porque nunca sabes cuando un archivo va a ser utilizado por algún elemento que no se te ocurrió en un principio ;) (Por ejemplo, el fichero de configuración de KDM también lo usa Mdkkdm, que una vez te das cuenta tiene su lógica, pero en el momento puedes sustituirlo por el rpmnew sin darte cuenta de dicha dependencia, como uno que me conozco yo y que escribe estas líneas... :P )
Aprovechando que al cambiar el fichero de configuración Mdkkdm dejó de funcionar, sustituí éste por GDM, ya que Mdkkdm ya no existe en Mandriva 2007 (era un paquete que quedaba sin actualizar de la 2006). En principio iba a usar KDM, pero en el repositorio contrib hay un paquete llamado "gdm-more-themes" que contiene un tema muy majo llamado Relaxing, así que para olvidarme de complicaciones usé el paquete en lugar de bajarlo directamente de GNOME-Look.org.
Al arrancar, udev muestra algunos errores relacionados con algunas reglas (que se encuentran en /etc/udev/rules.d) que añadí manualmente para cuestiones concretas. Utilizando draklog compruebo los logs del sistema en busca de coincidencias con la cadena "udev", y soluciono los problemas en las reglas (o elimino los archivos de reglas si ya no son necesarios).
Hecho todo esto, queda pasar a UTF-8 mi sistema, por un lado recodificando los nombres de los archivos (como se indica en Caracteres extraños en mis archivos y sus nombres: Cómo convertir $HOME a UTF8) y por otro utilizando draklocale para establecer la nueva codificación (ya que la actualización por urpmi, que yo sepa, no cambia la codificación del sistema a utilizar).
Una acción recomendable es entrar en el centro de control de Mandriva e ir visitando los distintos asistentes para que actualicen la configuración de los diversos elementos. Por ejemplo, harddrake2 se baja algunos paquetes determinados que considera necesarios, y en el caso de drakprinter, tuve que borrar mi impresora y añadirla de nuevo para que funcionase adecuadamente (quizás hubiese servido editar la configuración de la impresora ya existente para que volviese a reescribirla, pero tampoco tenía nada que no pudiese borrar y añadir de nuevo ;) ).
Queda comprobar, además, qué paquetes no fueron actualizados (porque ya no existen, porque cambió el nombre, etc). Para ello, se puede utilizar el procedimiento aquí descrito: ¿Cómo saber qué paquetes no fueron actualizados?, y según qué paquete sea, tomar una acción u otra.
Ahora que (en apariencia al menos ;) ) el sistema base ya funciona como debe, añado los repositorios de PLF free, free_backports, nonfree y nonfree_backports. Una vez configurados los repositorios, desde el mismo drakx11, al seleccionar el modelo de tarjeta gráfica de NVidia de la lista, él mismo descarga el último driver propietario disponible desde PLF y edita /etc/X11/xorg.conf. Sin embargo, aún no funciona todo lo fino que debiera, al menos cuando se trata de cambiar la configuración desde un driver a otro distinto, por lo que hay que realizar algún ajuste manual en dicho fichero de configuración.
Por meras cuestiones de manías mías, una vez incluido PLF en los repositorios no actualizo todo mediante urpmi --auto-select, sino que actualizo sólo algunos paquetes concretos a PLF, ya que algunos paquetes oficiales de Mandriva también están ahí. En algunos casos puede ser adecuado actualizar los de Mandriva a los de PLF, como mplayer, pero otros quizás no, como freetype (al menos, cuando lo hice en su momento, las fuentes se me empezaron a mostrar de forma bastante "fea" y tuve que volver a poner los de Mandriva).
Una vez hecho todo esto, queda echar un ojo con más detalle a los diversos programas de usuario y sus configuraciones, para comprobar que todo haya sido actualizado como debe y que no haya problemas, y para ver qué nuevas y jugosas opciones nos traen las nuevas versiones ;)
Y eso es todo en lo que respecta a la actualización pura y dura (sin contar instalar nuevos paquetes adicionales como el escritorio 3D y similares), a ver si a alguien le sirve de algo :)