[CentOS-es] epel o rpmforge+karan ?

[BlackHand]

On Thu, 2008-11-06 at 01:48 +0100, Santi Saez wrote:

> Veo un problema en esta situación.. mucha gente está trabajando por 
> separado. Lo ideal sería que todos los proyectos unificaran sus 
> esfuerzos.. así tendíamos mas paquetes, actualizados con mayor 
> frecuencia.. y al estar centralizado sería mucho mas sencillo para los 
> usuarios/desarrolladores/colaboradores, todos iríamos al mismo sitio 
> para colaborar o para descargar.. ahora según lo que quieras hacer vamos 
> a un repo o a otro, ¿que opinaís de esto, soluciones?

la gente de rpmforge, freshrpms, karan e incluso atrpms propusieron la
estandarizacion de un tag adicional al rpm para identificar el
repositorio de origen para asi poder manejar las dependencias entre
repositorios ademas de proveer los fuentes de los rpms (cosa q
ocasionaba problemas en fedora antes con fedora.us)

en su momento la gente de epel rechazo este item de los tag para repos
pero si quedaron claros en q si era imperativo dar los srpms para poder
saber al menos a lo q se enfrentan. kde-redhat y remi por ejemplo ahora
solitican q se tenga activado epel para manejar sus dependencias (y
ellos no estar metiendo paquetes de mas en sus repos) atrpms medio q
apoya a epel pero sigue con sus propios paquetes, eso si, sin toquetear
los paquetes base (a menos q actives atrpms testing)

karan ya habia comenzado con un esfuerzo similar al q esta haciendo epel
ahora mucho antes q este y con una intencion de ser lo mas compatible
posible a rpmforge (recuerdo q reporte un problema con el paquete clamav
q proveia karan q chocaba con el clamav q proveia rpmforge, al final
karan saco su paquete) el problema con epel es q este comenzo cuando
habia fedora extras asi q era facil diferenciar q paquetes iban en epel
(lo mismo con karan) cuando fedora unifico sus paquetes, la linea como q
no quedo tan definida.

Que unan esfuerzos ahora lo veo poco probable, pero la situacion ya no
es tan caotica como hace un buen tiempo atras, no es transparente el
pase de un repo a otro pero se pueden evitar transparentemente los
conflictos entre ellos. 

yo personalmente pienso q lo q le falta a RHEL y CentOS seria un sistema
tipo SuSE, donde construyen de manera automatica los paquetes a peticion
de los usuarios. Se podria usar Fedora (incluso Rawhide) para hacer
backport de paquetes a RHEL/CentOS de manera automatica (en mi
experiencia reconstruir rpms de Fedora en CentOS casi siempre se puede
hacer sin toquetear el srpm original, solo indicando el release al
momento de reconstruir) un sistema q construya automaticamente desde los
srpms de fedora y q si se detecta algun problema en la construccion, se
pueda aplicar algun parche para su construccion.

--
Yonsy Solis (aka BlackHand)