Bonjour

Le Monday 17 November 2008 16:16:27 Dominique Dumont, vous avez écrit :
> Salokine Terata <[EMAIL PROTECTED]> writes:
> > [ une bonne analyse ]
Merci beaucoup !

> Le seul élément qui puisse apporter des informations (notez que je
> n'ai pas écrit "scripts") sur la façon de gérer l'upgrade du composant
> version a vers composant version b est le composant version b. Pas
> l'applicatif qui utilise ce composant.
>
> >     - Vérification des injections de configuration:
> >             Tu controles que les includes et autres fichiers de
> >             conf modulaire (comme les sites-avaible) soient bien
> >             présent:
>
> Est-ce que tu penses aussi en vérifier le contenu ?
C'est justement la partie d'après.

>
> >     - Mise à jour éventuellement de ses configurations
> >       personnalisées en fonction d'une mise à jour réalisée sur
> >       les composants:
> >             Par exemple, rétablisement du lien, mise à jour de
> >             certains attributs ... etc.  met à jour ces
> >             configurations, ou indique à l'utilisateur que ton
> >             application ne sait pas se configurer automatiquement
> >             pour "telle version" du composant et qu'il va devoir
> >             éventuellement corriger le fichier "blabla" à la mano.
>
> Là, je suis perdu. Tu as des exemples ??
Exemple, si ton paquet OBM est dépend de apache2 (>=2.0.0) (cf. fichier 
debian/control de ton paquet)
Celà sous-entend que ton applicatif est compatible avec TOUTES les prochaines 
version d'Apache. On sait bien que c'est forcément vrai, car comme tu 
l'indique on ne connait pas encore les futures évolutions quant à la manière de 
le configurer. 
Cependant, si tu connais dejà à l'heure d'aujourd'hui les différentes 
spécifiaction des fichiers de conf (2.0, 2.1 ... etc), tu peux déjà "coder" ces 
conf.

Ainsi, si l'utilisateur upgrade son composant (ici Apache), c'est que tu 
procède "éventuellement" à la mise à jour de ta conf personnalisé de se 
composant. Si tu ne sait pas la gérer, alors:
 - Informe l'utilisateur qu'il utilise un composant qui n'est pas validé par 
ton applicatif, et qu'il peut être amené à downgrader ou corriger 
lui-même cette configuration.
 - Un autre garde-fou est de "brider" la version maximale du paquet au niveau 
de dépendance. C'est plus stricte car l'utilisateur ne pourrat pas 
upgrader son composant sans avoir à désinstaller ton applicatif (conflit de 
paquet).


> Pas de problème. C'est toujours bon de discuter :-)
>
> A+
Oui ca fait toujours du bien.

Bonne soirée.
Salokine



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Répondre à