Re: Nouveaux paquets [OBM]: Réflexion sur la Gestion des composants partagées
Bonjour
Le Monday 17 November 2008 16:16:27 Dominique Dumont, vous avez écrit :
> Salokine Terata <salokine.terata@free.fr> 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
Reply to: