Extemp”F”oraneo Linux

Cuando inicié la actualización a Breezy seguí los pasos recomendados: actualización de los repositorios y revisión de que estuviesen bien escritos. Requerimientos de existencia de algunos paquetes básicos (ubuntu-base y ubuntu-desktop). Ejecución de los comandos “apt-get update” y “apt-get dist-upgrade”. En el camino, como le ocurrió a una buena cantidad de personas, la actualización falló con el OpenOffice. A partir de aquí todo se condujo erráticamente y a pesar que desinstalé el OpenOffice y pude proseguir, cuando todo terminó me encontré con varios problemas muy desagradables. Ya me había preparado para evitar el colapso del servidor X, más aún cuando tengo NVidia GForce FX5200 y aunque con el paso de Warty a Hoary eso no ocasionó sino una instalación de los respectivos módulos al nuevo kernel (y esto fue automático) no ocurrió así con Breezy. Obviamente dejó de funcionar el servidor X por lo que tenía copiado otro archivo de configuración de Xorg sin Nvidia (siempre tengo una copia con el driver VESA, xorg.conf.vesa ) lo renombré, arranque las X y comencé la tarea de bajar los módulos del kernel para Nvidia (nvidia-kernel-common). Coloqué el xorg.conf para nvidia en su lugar y reinicié el servidor X sin problemas (cargando previamente el módulo de nvidia). Pero tanto con vesa como nvidia me enfrenté a lo que más me irritó: mi sesión en Gnome (escritorio que uso por defecto) no entró. Todo parecía indicar un fallo en Nautilus. Ingresé a una sesión a través de XFCE y allí reinstalé Nautilus y todos sus derivados. No funcionó. Reinstalé todo lo que se me ocurrió, las librerías gtk, gdk, todo lo concerniente a Gnome, pero en vano. Disparando el Nautilus desde una consola observé un fallo en el intento de cargar la librería /usr/lib/libnautilus-private.so.2 Como mencioné anteriormente, reinstalé Nautilus y las librerías relacionadas, pero sin éxito. ¿Qué podía estar ocurriendo entonces? Volví a una sesión de XFCE e intenté ejecutarlo desde allí. Se inició sin problema. Utilizando el método de reducción, por refinaciones sucesivas del problema, busqué qué podía tener la sesión de XFCE que no tuviera la de Gnome. Así, revisé los archivos de arranque que son llamados por el GDM(Gnome Display Manager) para ingresar a una sesión. XFCE declara explícitamente la ruta de las librerías, cosa que no ocurre con la gnome-session. Suponiendo que algo, entonces, estaba impidiendo a Nautilus la carga dinámica de la librería que señalé más arriba, probé a declarar la ruta, desde una consola en la sesión de Gnome (sin Nautilus). Exporté la variable LD_LIBRARY_PATH con las rutas como valor /usr/lib:/usr/local/lib:/usr/X11R6/lib y probé de nuevo. ¡Éxito! Intenté por dos días investigar por qué no se producía la carga dinámica de las librerías, sin necesidad de una declaración directa. No lo logré. Aún lo desconozco (si sabes la respuesta házmelo saber). Luego intenté dos formas de que la sesión de Gnome entrara dignamente, como lo haría en un sistema bien establecido. Mi primer intento fue con el programa ld.so.preload-manager que permite pre-cargar en memoria las librerías que se le indican. El archivo /etc/ld.so.preload contiene la o las librerías que se le han asignado previamente, luego de lo cual, el sistema una vez que arranca, las coloca en memoria. Para los efectos de la “gnome-session” funcionó adecuadamente. Nautilus arrancó sin problemas. La cuestión es que programas que usan las librerias libgtk1.2 como *Audacity* o el *XMMS* no arrancaban. Tuve que buscar otra manera, prescindiendo del “preloader”. Me fabriqué un pequeño y muy simple script para la sesión de gnome al que denominé “gnome-session” y renombre el binario original por “gnome-session.ori” el cual es llamado por el script luego que se declaran las rutas de las librerías. Así es como le tengo actualmente y no hay diferencia perceptible cuando desde la GDM llamamos a una sesión de Gnome. El otro problema molestoso que apareció fue con programas como el “Selector de lenguajes” y el “Gestor de actualizaciones”, ambos requieren de Python 2.4 y en particular dependen de las librerías wxGTK que mostraron problemas. Al igual que en el caso anterior, a pesar que las reinstalé, no hubo buenos resultados. De nuevo intenté con la pre-carga y el sistema entró en un bucle infinito y colapsó, incluyendo la consola, en la que no podía escribir nada. Así, ingresé desde un live-cd y eliminé la librería en el /etc/ld.so.preload. Una vez en mi sistema elaboré otro script (apenas tres líneas) para cada uno de los programas, renombrando los binarios y arrancándolos desde el script: #!/bin/bash /usr/sbin/ld.so.preload-manager -y /usr/lib/libgtk-x11-2.0.so.0 /usr/bin/gnome-language-selector.ori /usr/sbin/ld.so.preload-manager -r /usr/lib/libgtk-x11-2.0.so.0 El anterior es el script de “gnome-language-selector” el Selector de lenguaje en Gnome 2.12. La primera línea lleva a memoria la librería que no se carga dinámicamente, aún con las rutas declaradas (Python 2.4 sucumbe y el programa no arranca). La utilidad ld.so.preload-manager añade, con la opción “-y” la librería (que se carga) en el archivo /etc/ld.so.preload entonces llamamos al binario (el cual renombré con la extensión “ori” por “original”) y luego, cuando el programa se cierra el precargador es instruído, con la opción “-r” para remover la librería (que se descarga). De tal forma se evita el bucle infinito y los programas funcionan como si nada. Como puede observarse, mi Breezy tiene “marcas de guerra”. He intentado encontrar una solución “limpia” y consistente, pero no la he encontrado. Tal vez la tenga en frente de mi nariz y lo desconozco, tal vez hay métodos mejores para sobrellevar las deficiencias en la instalación, pero hasta ahora, con las soluciones rudimentarias que me he fabricado el sistema, en esos aspectos, está trabajando como era de esperarse. Pero si alguien conoce las razones (que no encontré) y por ende, sus eventuales soluciones definitivas, pues hacermelo saber. ;-)