Regole per la creazione delle configurazioni VOMS

Gestione delle configurazione dei componenti

Ogni componente del sottosistema dovrebbe avere due configurazione per ogni release, una da lockare contro la project configuration glite 3.1 e una contro glite 3.2. La configurazione per glite 3.2 si distingue da quella per 3.1 grazie al suffisso _GL32.

Esempio:

Glite 3.1

Glite 3.2

1. Clonare l'ultima conf funzionante (i.e. che builda correttamente su tutte le piattaforme) del sottosistema org.glite.voms.
2. Clonare l'ultima conf funzionante dei pacchetti che devono costituire il sottosistema. Non e' necessario aggiornare le dipendenze fra i pacchetti all'interno del sottosistema, basta aggiornare il TAG del CVS per quei pacchetti che ne hanno bisogno, come descritto nella tabella in fondo alla pagina.
3. Linkare le nuove configurazioni a quella di sottosistema
4. Lanciare un remote build per le piattaforme slc4_ia32_gcc346 e slc4_ia64_gcc346, mettendo come project config glite-branch-3_1_0, come illustrato qui sotto:

Tabella moduli e Tag

nome conf	Ulimo TAG CVS funzionante	N. B.
org.glite.security.voms	glite-security-voms_R_1_8_7
org.glite.security.voms-admin	glite-security-voms-admin_R_2_0_15_1	per l'admin basta solo questo modulo
org.glite.security.voms-api	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-c	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-cpp	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-api-java	glite-security-voms_R_1_8_7	usa tag sul codice sorgente di org.glite.security.voms
org.glite.security.voms-api-noglobus	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-clients	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-config	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente
org.glite.security.voms-mysql	glite-security-voms-mysql_R_3_0_7
org.glite.security.voms-oracle	glite-security-voms-oracle_R_3_1_2
org.glite.security.voms-server	<nome-modulo>_R_1_8_3	non fa checkout di codice, ma e' opportuno cmq specificare un tag funzionante, nella maggior parte dei casi basta lasciare quello della configurazione precedente

-- AndreaCeccanti - 08 Sep 2008