[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]Raymond Hall Haro wrote:
Sandino Araico Sanchez wrote:Lo que yo hice con Red Hat durante muchos años fue ir borrando paquetes uno por uno con rpm -e y reemplazarlos por un compilado propio en /usr/local. Con Debian hubiera hecho lo mismo.Pero te paso lo que describes en el mail. Salvo algunos paquetes, yo prefiero bajarme el src.rpm, editar el spec o parchar el fuente y rehacer el rpm. Tiene la ventaja de que cuando liberan una nueva version del fuente recomplias el rpm y listo, y cuando la distro libera un nuevo rpm te bajas el src.rpm y le aplicas los parches tuyos. De ese modo no desmadras tu arbol de dependencias.
Para ese tipo de movimientos prefiero usar gentoo. Si hay una dependencia que no me gusta le agrego -dependencia a $USESi hay un ebuild que no me gusta pues lo edito y lo dejo en /usr/src y de ahí compilo (aunque no me he puesto a buscar a consciencia para encontrar un ebuild que no me guste, generalmente están bién hechos y son muy sencillos). Si hay un paquete que no está en Gentoo pues ahí si ni pedo o lo compilo a pata y lo instalo en /usr/local o me encuentro un ebuild parecido, lo copio y lo edito para que me instale mi paquete que quiero (sucede mucho con los módulos de Perl). Cuando hay una nueva versión del fuente y no ha llegado mi ebuild a los ports pues copio mi ebuild anterior, le cambio tres o cuatro caracteres en una o dos líneas (números de versión y esas cosas) y lo instalo.... Desde luego, no intento que cambies de Fedora a Red Hat porque si no ¿quién me resolvería mis dudas sobre Fedora? pero es nomás para hacer más interesante la plática de cómo le hace cada quién con la distro que le gusta....
.
Solo en contados casos no tienes alternativa (por ejemplo cuando tienes un rpm cuyo fuente no usa un soname versionizado e instalas una nueva version de la libreria en otro lado, pero a fin de cuentas ese no es ni siquiera problema de rpm sino de un desarrollador vaqueton que escribio libtiff.so en vez de libtiff.so.3)
En las recomendaciones para hacer ebuilds viene una de que en esos casos hay que bajar el spec del RPM o deb que si resolvió el pedo y copiar el parche y el método que usaron para resolver el pedo.....
Salu2, Ray _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/
-- Sandino Araico Sánchez -- Melón se comió las plumas.... _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/