[Partecipa-net-devel] Nuova release RC3_FINAL

[Enrico A. <an...@na...>]

Rilasciata la release RC3_FINAL.
Questa release e' marcata RC3_FINAL nonostante sia feature complete =20
solo perche' non ho potuto testarla su altre installazioni, e non ha =20
passato un periodo di utilizzo reale da parte degli utenti: e' =20
comunque stata testata ripetutatmente sulla mia macchina di sviluppo e =20
dovrebbe essere completa nonche' funzionante.

Ho sistemato alcuni bugs della RC2, il piu' grave nel Makefile, che =20
causava un errore verso la fine di "make install".
Inoltre ho sistemato alcuni bugs minori in sendPage e nel cgi-bin.

Aggiunto un sistema di logging separato dal log di apache, per =20
chiarezza e per velocizzare il debugging: ora tutti i log vanno in =20
/var/log/partecipa.log.

Implementato ed integrato nel Makefile il sistema di upgrade per i =20
templates ed i fogli di stile: il sistema e' autodocumentato, nel =20
senso che durante la normale procedura ./configure, make l'utente =20
viene avvertito del nuovo target "make upgrade" e del suo utilizzo; la =20
procedura funziona in questo modo: a fianco della directory che ospita =20
i templates, solitamente =20
/usr/local/Partecipa.net/partecipa.base/lib/servers/pub/templates e' =20
stata creata una directory custom_templates: qui vanno copiati i =20
template modificati rispetto allo standard: se il sistema trova un =20
template personalizzato in questa directory con lo stesso nome di =20
quelli standard, verra' visualizzato quello personalizzato, evitando =20
cosi' eventuali sovrascritture con conseguente perdita delle =20
personalizzazioni durante l'installazione.
In aggiunta a questo sistema, se l'utente non ricorda quali files ha =20
modificato (!!) viene proposta dopo il make l'esecuzione del nuovo =20
target "make upgrade", il quale lancia una procedura che legge la =20
configurazione di unox1.conf uscente dal make appena eseguito, ricava =20
i path di templates e stylesheets (che se l'utente non ha sbagliato il =20
configure corrispondono all'installazione precedente **), calcola il =20
checksum MD5 dei files attualmente installati e li confronta con un =20
suo database interno contenente i checksum di tutte le release finora =20
rilasciate: qualora vengano riscontrate differenze viene presentata =20
alla fine una lista dei files modificati, e vengono presentate le =20
istruzioni su come procedere, che consistono nel copiare a parte i =20
files indicati, eseguire "make install" e ricopiare i files salvati =20
nella directory custom_templates.
Un lavoro analogo viene fatto con i fogli di stile, solo che purtroppo =20
per questioni inerenti l'implementazione del codice non e' stato =20
possibile implementare lo stesso meccanismo per i CSS: l'utente viene =20
comunque avvertito se i files sono diversi, e da li e' possibile unire =20
manualmente le modifiche o sovrascrivere la nuova versione di CSS con =20
la propria.
L'upgrade dello schema di database deve comunque venire eseguito a =20
mano perche' ci sono troppe varianti in gioco (versione di Postgres, =20
versioni di perl) e si rischiava di perdere tutti i dati preesistenti.

NOTE:
** in ogni caso se l'utente sbaglia il configure il sistema avverte =20
che non riesce a trovare i files, quindi l'utente e' incoraggiato a =20
ripetere la procedura.