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/goals.shtml#packages
[2] http://www.pkgjam.org/
[3] http://www.modeemi.fi/~tuomov/b/arch.../03/T19_15_26/
[4] http://wiki.rpath.com/wiki/Conary
[5]
http://beranger.org/index.php?page=d...asonable-relea

ciol a écrit :
> 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/goals.shtml#packages
> [2] http://www.pkgjam.org/
> [3] http://www.modeemi.fi/~tuomov/b/arch.../03/T19_15_26/
> [4] http://wiki.rpath.com/wiki/Conary
> [5]
> http://beranger.org/index.php?page=d...asonable-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