-Yum- sucks, -make install- rules

Software Update Hoy aprendí que es mejor compilar que confiar en los manejadores de paquetes, en especial en uno tan nefasto como Yum, el gestor de paquetes en RedHat/Centos.

Seguro soy yo el que no entiende que quiere Yum que haga, porque hoy pase buen rato peleando para instalar Subversion y usarlo con Apache en un servidor VPS. O no tengo idea de que -repositorios- son los correctos, porque los por defecto andan perdidos.

En un mundo lleno de arco iris, uno solo tendría que seguir un sencillo tutorial para tener Subversion trabajando con Apache. Pero como en el mundo real Yum decidió instalar mod_dav_svn.so en una ruta diferente a la que debía ser (/usr/local/apache/modules/) y no encontré la forma de que Yum me dijera donde estaban instalados los archivos del paquete XXXX. Total pase un buen rato buscándolo, para cuando lo encontré y logre cargarlo en el httpd.conf, fue solo para encontrar otra piedra en el camino:

Cannot load /usr/local/apache/modules/mod_dav_svn.so into server:
/usr/lib/libsvn_fs_base-1.so.0: undefined symbol: db_create

Resulta que debía instalar BerkeleyDB para resolver ese error, cosa que no quería hacer.

Lo irónico de asunto fue que luego de pasar peleando con Yum, la mejor solución que encontré fue recompilar Subversion deshabilitando el -soporte- para Berkeley y con las rutas correctas para Apache. Se tomó unos pocos minutos y hasta agregó los módulos al httpd.conf, todo funcionó de maravilla.

Si hubiera sabido, habría compilado todo desde cero y evitarme tantas vueltas, ahora hasta tengo la versión que quiero de Subversion.

Se supone que los administradores de paquetes te deben simplificar la vida, pero parece que el servidor tiene los peores repositorios … o simplemente no entiendo como pudieron haber desarrollado Yum. make install rules.

PD: se que se puede instalar apt-rpm, pero si solo necesito instalar un paquete muy pocas veces, no considero que valga la pena.

8 thoughts on “-Yum- sucks, -make install- rules

  1. Esa es justamente, estimado compañero, la razon por la que uso Gentoo/Slack/Debian.

    Siempre es mejor compilar desde 0, que hacerce bolas con los packages managers de las distros novatas.

    Si se van a usar PM, mejor usar los maduros apt-get, es el claro ejemplo.

    Saluditos.

  2. Yo he utilizado svn en fedora y 0 clavos, creo que tu problema si fue de repositorios, los repositorios extra siempre (o casi siempre) son compatibles con el oficial peeeeero casi nunca entre ellos, BTW aptitude si puede con eso.

  3. @Alejandro, tendremos que buscar provedores con opción a Debian entonces, pinche Centos.

    @tuxtor, si esos repositorios están algo chafas… para instalar Ruby tuve que bajar los RPMs porque desde los repos no quedo muy bien =/

  4. Mi estimado j_aroche lo que pase es que quien se acuesta con niños mojado amanece, no la verdad Centos es bueno pero por lo general te instal cosas demas, si al instalar Debian no usas Taskel y le decias que no queres dependencias no necesarias usando este comando:

    apt-config dump | grep Recom | sed ’s/1/0/’ > \
    /etc/apt/apt.conf.d/05userconf

    Por eso muchos preferimos Debian pero que bueno que no te da pereza compilar.

  5. Estimado compañero, su problema fue un poco de desconocimiento del sistema que estaba usando.

    yum nunca le dirá donde instala las cosas puesto que solo es un frontend, para eso se tiene el comando rpm, en su caso bastaría con usar:

    rpm -ql nombre_del_paquete

    Para saber que instalo y en donde ( ver opciones rpm con rpm –help ).

    Recordar que yum usa una cache para hacer búsquedas de paquetes y si esta es una cache algo vieja ( a pesar de que se actualiza con frecuencia ), precisamente si actualizaron los repositorios, es mejor limpiar la cache antes de hacer operaciones si se tienen problemas para ubicar paquetes:

    yum clean all

    Otra cosa, para centOS es recomendable usar los repositorios EPEL que provee fedora, esto le da un extra ( revisar EPEL en google ) de valor agregado a CentOS como distribución.

    Por cierto, para compilar paquetes para estas distribuciones se descarga generalmente el *.src.rpm del paquete, se modifica y se reconstruye el rpm.

    Para concluir, deberías saber que el sitio por defecto de los modulos de apache al menos en estas distribuciones es: /usr/lib/httpd/modules/ y no /usr/local/apache/modules/ el ultimo path es para debian y derivados (creo ) o para paquetes compilados desde las fuentes.

    Como consejo final, sin ánimos de ofender puedo decir que el problema es del operario, no de la herramienta.

    Espero tome mi comentario como una critica constructiva.

  6. @Richzendy, Gracias por los datos y entiendo bien lo del desconocimiento del sistema, he trabado (y gustado) mucho más con Debian que con (basados en) RedHat.

    Días después de escribir esto, caí en cuenta que debía buscar los archivos de cada paquete con rpm.

    Lo de la ruta de apache, pues en el VPS está instalado en /usr/local/apache y no en /usr/lib/http . Todos los directorios relacionados (/etc/httpd, etc) apuntan hacia el primero.

    En fin, me es más fácil buscar los *.rpms en google o compilarlos.

  7. Lo bueno de usar RPMs (o Debs), es que actualizar se hace mucho más sencillo, ya que manejas versiones automaticamente.
    Subir de Pidgin 2.5.4 a 2.5.5, es simplemente un rpm -Uvh pidgin*, por dar un ejemplo.

    Como menciona Richzendy, Yum es el front-end de RPM, y facilita mucho mas administrar al servidor/desktop, al buscar y actualizar, remover y hacer obsoletos los paquetes sin necesidad de ir de cacería de RPMs.

    Por último, si vas a compilar paquetes, definitivamente los SRPMs son la opción, tal como lo menciona Richzendy, pues igual los compilas para tu maquina, pero dejas a su vez un RPM que puedes versionar, y remover sencillamente con unos comandos.

    Saludos!

  8. Hola a todos…les cuento que partiendo de lo que os comenta nuestro compañero me olvide del Yum y recompile mi version de subversion, vaya sorpresa cuando al reiniciar apache me salio error entonces entre a recompilar apache con los modulos dav y luego recompile subversion, sin embargo al volver a subir apache me arroja
    httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/mod_dav_svn.so into server: /usr/local/apache2/modules/mod_dav_svn.so: undefined symbol: dav_register_provider

    os agradeciendo la ayuda que podais prestar

Comments are closed.