Vers un nouveau modèle de développement

Le
ciol
Les applications peuvent se diviser en plusieurs catégories.
Nous distinguons :

A = Les applications finales. Exemples :
OOo, firefox, Gimp, apache

B = Les applications dont dépendent celles de A. Exemples :
gtk, libpng, Java, python

C = Les applications dont celles de A peuvent dépendre, mais d'une façon
moins forte, ou qui sont relativement importantes pour le système.
Exemples :
make, tar, grep

D = Les applications critiques. Exemples :
le noyau, libc, grub, bash, xorg (qui selon les cas peut se retrouver en B)

-

À partir de cette analyse nous pouvons faire quelques remarques.

* Dans l'idéal, les applications de A peuvent être mises à jour dès
qu'il y a une nouvelle version stable en amont.
La possibilité d'avoir plusieurs branches (exemple apache 2.0.X, apache
1.3.X), est un plus considérable, et permet de laisser une grande partie
de la maintenance aux développeurs amont, la distribution se contentant
de packager.

* Une nouvelle version d'une application de A peut nécessiter une mise à
jour d'une de B. Ce qui peut entraîner des recompilations de A, ou en
tout cas de nouveaux tests à effectuer.
Ce sujet sera traité en profondeur dans une prochaine étude (certaines
techniques permettent de remédier en parti au problème). On peut déjà
conseiller aux intéressés la lecture de [1], [2] et [4].

* Les mises à jour de B et C doivent se faire au cas par cas, et sous
certaines conditions.

* Un type d'application peut se retrouver dans plusieurs ensemble à la fois.
Prenons par exemple un gestionnaire de bureau (KDE ou Gnome). Une
distribution peut décider, afin de satisfaire l'utilisateur, de choisir
KDE comme bureau par défaut, de le placer en C, et tous les autres
environnement de bureau en A. L'utilisateur choisira alors s'il veut la
stabilité ou les dernières avancées.

* D'une façon général, il est difficile de faire une partition des
applications.


Les liens [3] et [5] (surtout [3]), sont en rapport.


[1] http://www.dragonflybsd.org/docs/go...l#packages
[2] http://www.pkgjam.org/
[3] http://www.modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/
[4] http://wiki.rpath.com/wiki/Conary
[5]
http://beranger.org/index.php?page=...able-relea
Publicité
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Lliane
Le #6001861
Les applications peuvent se diviser en plusieurs catégories.
Nous distinguons :

A = Les applications finales. Exemples :
OOo, firefox, Gimp, apache

B = Les applications dont dépendent celles de A. Exemples :
gtk, libpng, Java, python

C = Les applications dont celles de A peuvent dépendre, mais d'une façon
moins forte, ou qui sont relativement importantes pour le système.
Exemples :
make, tar, grep

D = Les applications critiques. Exemples :
le noyau, libc, grub, bash, xorg (qui selon les cas peut se retrouver en B)

----------------

À partir de cette analyse nous pouvons faire quelques remarques.

* Dans l'idéal, les applications de A peuvent être mises à jour dès
qu'il y a une nouvelle version stable en amont.
La possibilité d'avoir plusieurs branches (exemple apache 2.0.X, apache
1.3.X), est un plus considérable, et permet de laisser une grande partie
de la maintenance aux développeurs amont, la distribution se contentant
de packager.

* Une nouvelle version d'une application de A peut nécessiter une mise à
jour d'une de B. Ce qui peut entraîner des recompilations de A, ou en
tout cas de nouveaux tests à effectuer.
Ce sujet sera traité en profondeur dans une prochaine étude (certaines
techniques permettent de remédier en parti au problème). On peut déjà
conseiller aux intéressés la lecture de [1], [2] et [4].

* Les mises à jour de B et C doivent se faire au cas par cas, et sous
certaines conditions.

* Un type d'application peut se retrouver dans plusieurs ensemble à la
fois.
Prenons par exemple un gestionnaire de bureau (KDE ou Gnome). Une
distribution peut décider, afin de satisfaire l'utilisateur, de choisir
KDE comme bureau par défaut, de le placer en C, et tous les autres
environnement de bureau en A. L'utilisateur choisira alors s'il veut la
stabilité ou les dernières avancées.

* D'une façon général, il est difficile de faire une partition des
applications.


Les liens [3] et [5] (surtout [3]), sont en rapport.


[1] http://www.dragonflybsd.org/docs/go...l#packages
[2] http://www.pkgjam.org/
[3] http://www.modeemi.fi/~tuomov/b/archives/2007/03/03/T19_15_26/
[4] http://wiki.rpath.com/wiki/Conary
[5]
http://beranger.org/index.php?page=...able-relea

Et le kernel, il faut le fork ?


--
How are you gentlemen? All your base are belong to us.
-=> Depiets Simon || EPITA || Promo 2011 || Spé B2 <=-
Lliane.com

Publicité
Suivre les réponses
Poster une réponse
Anonyme