--- "sandman42@xxxxxxxxx" <sandman42@xxxxxxxxx> ha
scritto:
> > > ho un pc con fedora, su cui ho sviluppato
> un'applicazione, e su cui sono
> > > installate tutte le librerie "giuste".
> >
> > In che senso giuste ? L'applicazione deve
> continuare a funzionare anche se
> > le librerie si evolvono.
>
> Certo, ma chi mi obbliga a farle evolvere? Mi
> spiego: se l'applicazione è sviluppata con un certo
> set di tool, kernel e librerie, diciamo con una
> certa distribuzione, e funziona come deve, perché
> mai devo aggiornare il kernel e/o le librerie,
> tenuto conto che non ho problemi di sicurezza, a
> meno che non trovi bachi risolti in versioni
> successive o mi servano le feature aggiuntive delle
> versioni successive?
Diciamo così ... è un pò che mi occupo di queste cose
e forse sono diventato un pò cinico. E' possibile che
questa applicazione abbia passato una test suite quale
io neppure mi sogno e che fa impallidire qualsiasi
altra che io abbia visto, e ora come ora lavoro in un
ambito in cui le cose vengono fatte *piuttosto bene*,
ma è anche possibile che sia scattata la sindrome del
"finalmente funziona dopo tanta fatica, congela tutto
che non vogliamo grane e fattura".
> Il problema, per me, è fare una gestione della
> configurazione, nel senso che la mia applicazione è
> un qualcosa che va in una postazione remota, in cui
> non c'è interazione umana, e che deve funzionare
> sempre.
In questo caso, devi aggiungere yum alla tua scatola
degli attrezzi, vedi sotto.
> Ora, nulla mi vieta che con le librerie versione
> 1.2.3 funzioni, ma che le 1.2.4 introducano un baco
> che magari mi blocca l'applicazione, e che sia
> risolto dall 1.2.5, io mi devo gestire questo
> casino, che se ho bisogno di feature della 1.2.4 non
> presenti nella 1.2.3 può avere senso ma che, in
> quest'ultimo caso, gestisco a livello di deployment
> e test interno, e solo dopo che il test interno è
> passato, passo ad un test esterno, e se passa anche
> questo rilascio con la nuova libreria.
Osservazione: per questo scenario, Fedora non è la
distribuzione giusta. Lo scopo di Fedora è provare
cose nuove, in particolare SELinux, per vedere che
cosa si rompe e come si aggiusta.
Per gestire questo scenario, si usano due repository
yum dedicati. Il primo si inizializza con una copia
del repository di fedora: la cosa avrebbe dovuto
partire quando lo sviluppo era a buon punto ma lungi
dall'essere completato.
Questo primo repository di staging è "corretto" quando
da esso è possibile installare l'applicazione con
yum install applicazione
con totale successo. Ciò conclude lo sviluppo.
Il "rilascio" consiste nel creare un secondo repo a
partire da questo primo e le macchine che devono
essere installate vengono installate dal repository di
rilascio.
Successive evoluzioni di librerie si gestiscono
copiando le nuove librerie nel repository di staging,
validando il buon funzionamento con la test suite di
cui sopra s'è detto e solo al buon esito aggiornando
il repository di rilascio.
I due repository possono felicemente convivere su uno
stesso host, vengono distinti in base alla URL.
> Quindi che mi interessa aggiornare in casi diversi?
Correzione di bug nelle librerie. Il fatto che
funzioni ora non assicura che non vada a stimolare bug
in futuro, e il linking statico oltre a scivolare in
tutta una serie di comportamenti rischiosi (in
particolare per eseguibili multithreaded) quello sì
obbliga a rifare tutto da capo.
> Ok x il discorso rpm. Volevo evitare di imbarcarmi
> nel casino del .spec e compagnia cantante.
Gli .spec possono risultare complicati se vengono
usati per un programma che non si installa a dovere
con
configure; make; make install
e in questo caso il problema è a monte, ovvero non
aver fatto ricorso agli autotools.
Davide Bolcioni
--
There is no place like /home.
Inviato da Yahoo! Mail.
Il servizio di posta con lo spazio illimitato.
http://it.docs.yahoo.com/mail/overview/index.html
|