Las mil y una distribuciones

Sabido es que hay cientos de distribuciones de GNU/Linux dando vueltas, y que de cada una conviven varias versiones al mismo tiempo. Es decir, unos usuarios tienen Fedora, otros Ubuntu, otros Arch, algunos Mint, unos pocos Slackware, aquel usa Gentoo, un amigo OpenSuse, etc, etc, etc. Y además, supongamos que solo existiera Ubuntu, alguno usará la de 32 bits, otro la de 64, alguno seguirá con la 10.04 porque es LTS, otro tendrá la 12.04 porque le gusta tener siempre lo último, el más pacífico tal vez corra la 11.10 porque aún no aplicó las actualizaciones, y hasta uno por alla con un hardware viejo y raro se quedó en la 9.10 porque es la única que le reconoce todo y le anda rápido con su poca memoria.

Tanta variedad trae problemas (y ventajas, pero vengo a plantear algunos problemas). Para empezar, los programas de terceros de los que dependen ZinjaI o PSeInt varían enormemente. Por ejemplo, si quiero correr algo en una terminal gráfica, ¿uso xterm? o ¿konsole? o ¿gnome-terminal? ¿o qué?. Supongamos que uso konsole, los argumentos que recibía en kde3 eran unos, pero en kde4 son otros, y hasta varían entre versiones de kde4. O supongamos que uso gnome-terminal. Hasta cierta versión de gnome uno lanzaba un proceso en esta terminal y esperaba a que termine, pero a partir de no se cuando empezó a lanzar el proceso algo así como en segundo plano, entonces el comando que hace la llamada finaliza enseguida, aunque el proceso que quería ver tal vez ni siquiera alcanzó a comenzar. Otros casos podrían ser instalar íconos y asociar tipos de archivos con los muchos exploradores de archivos (soluciones como xdg empiezan a parecer estándar pero aún no están en todos lados), o lanzar un comando como administrador (gksudo es lo más común, pero tampoco está en todos lados).

Y ese era el problema "fácil". Se puede solucionar fácilmente (aunque fácilmente no quiere decir con poco trabajo). A veces no queda otra que agregar una pila de ifs y verificaciones varias para preguntar qué es lo que hay en cada sistema y determinar luego cómo llamarlo (lo que yo hago es establecer un orden de prioridad, y los voy probando invocar uno por uno con el argumento "--version" y analizando la salida hasta que alguno responda como quiero). De alguna forma, tal vez trabajosa y poco elegante, se va arreglando. Pero el problema que más me preocupa es la compatibilidad de los binarios. Es decir, si hago un programa que utiliza una biblioteca, tengo que decidir si voy a utilizar los binarios de esa biblioteca que ofrece la distribución (lo que se conoce como enlazado dinámico), o si voy a incluir los mios en mi ejecutable (lo que se conoce como enlazado estático) para asegurarme de que no falten. La primer opción sólo es cómoda (desde el punto de vista del usuario) para biblioteca muy muy usadas que sabemos que no pueden faltar (gtk por ejemplo), la segunda es ideal para cosas más raras. Si siempre usara el segundo enfoque, tendría que distribuir ejecutables o instaladores gigantes (porque contendrían muchas bibliotecas y algunas bastante grandes). Por otro lado, puede haber varias compilaciones muy diferentes de una misma versión de una misma biblioteca (como me pasa con wxWidgets, que yo uso la versión ansi, pero las distribuciones suelen incluir en sus repositorios la versión unicode), y todo sin contar que las bibliotecas dependen de otras bibliotecas, y que además, hay casos como la libc, que tenemos que usar sí o sí los binarios del sistema para no meter la pata.

En conclusión, distribuir algo compilado en GNU/Linux puede ser un dolor de cabeza. O incluimos mil versiones y una pila de bibliotecas y hacemos una descarga gigante, o intentamos apostar por lo seguro. Y apostar por lo seguro para mi implica tres puntos. El primero es evitar utilizar demasiadas bibliotecas. Esto no se si es posible o siquiera recomendable en muchos casos, pero en grandes toolkits como wxWidgets, uno puede desactivar partes que no necesita cuando configura la compilación de la biblioteca para que sus binarios tengan menos dependencias. El segundo punto es enlazar dinamicamente sólo contra bibliotecas muy muy comunes, y además, a versiones viejas de esas bibliotecas. Porque si uso versiones muy nuevas una distribución desactualizada me traerá problemas, pero para el caso contrario se supone que puedo confiar en cierto nivel de compatibilidad hacia atrás. Entonces es más seguro una versión antigua, aunque en realidad por versión digo subversión o revisión, ya que si la versión cambia podría tener problemas igual (como me paso con la libjpeg, en muchas distribuciones se incluye la versión 6, pero en otras muy nuevas solo la 8). Y el tercer punto es enlazar estaticamente todo lo que el usuario generalmente no tendrá en su sistema o le será difícil de conseguir (tal vez porque no consiga la versión que quiero), y esto es lo que hago por ejemplo con wxWidgets (por lo que dije de ansi/unicode) y SFML (porque cuando empecé con MotoGT algunas distros tenían la 1.5 y yo usé la 1.6). Como plan C, para casos más extraños siempre se puede jugar un poco con la variable de entorno LD_LIBRARY_PATH para usar o no usar algunos objetos que podemos incluir en el paquete por las dudas, como hacen programas como googleearth por ejemplo (o como hago con graphviz en ZinjaI).

Entonces, para generar los ejecutables para GNU/Linux, no uso mi Slackware, por ser una distribución poco frecuente entre mis usuarios (y porque yo le actualicé desde fuentes casi todo así que ni siquiera es un slackware de serie). Lo que uso son un par de Ubuntus (uno de 32 y uno de 64) que tengo instalados en máquinas virtuales con Virtual Box. Siempre trato de usar Ubuntus con un par de años de antigüedad para asegurarme de que les funcione a los desactualizados. Pero igual recientemente me vi obligado actualizarlos un poquito (pase del 9.04 al 10.10) porque hacían cosas extrañas en distribuciones más nuevas: si bien encontraba todas las bibliotecas y corría sin problemas, algunas operaciones (como el drag and drop de texto en ZinjaI) hacían explotar el programa, u otras se comportaban digamos que extraño (por ejemplo cuando se ingresaban ñs o acentos en el código fuente). Luego de algunas pruebas concluí que era problema de versiones, y la actualización solucionó casi todo. Así que debo mantener esas máquinas virtuales en el pasado, pero no tan lejos, para obtener el mejor resultado, y poder ofrecer solo un par de binarios para todas las distribuciones.

Y para terminar, queda decir que a estos binarios los distribuyo "sueltos" en un tgz simple, y no en un paquete rpm, deb, o lo que sea para el gestor de una distribución X, porque para que funcionen no se necesita más que descomprimirlos (en cualquier lado, no importa donde). No hay proceso de instalación ni configuración. Si hay que hacer algo adicional (como crear íconos o alguna configuración inicial), lo hará el ejecutable en su primer corrida. Además, dado que actualizo seguido mis programas, para mí es mucho más fácil y rápido empaquetarlos y subirlos de esta forma. Alguna vez hice paquetes autoextraibles para PSeInt porque había visto la idea en el instalador del driver oficial de NVidia (básicamente es un script de bash con un tgz concatenado al final, el script corta la parte del tgz, extrae los archivos y hace la instalación con una bonita interfaz de consola, es fácil y elegante para quien se lleva con la consola), pero creo que es realmente más fácil un tgz estándar, que el usuario vea qué tiene adentro y lo descomprima como más le guste. De cualquier modo, si alguien quiere armar el paquete deb, rpm, o lo que sea, para su distribución y compartirlo también será bienvenido.