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)
_______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
