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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lliane
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.
-- How are you gentlemen? All your base are belong to us. -=> Depiets Simon || EPITA || Promo 2011 || Spé B2 <=- Lliane.com
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.
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.
