Le système de développement par « component », ou « composants » en français, est de mettre en place différentes composantes créant ensemble une distribution. Au lieu d'avoir un développement par paquets séparés les uns des autres et architecturés dans une suite de unstable/testing/stable (pour reprendre le schéma Debian par exemple).
Là on se retrouve avec des composants. À noter que FireFox n'est PAS un composant, mais un simple paquet, car il ne représente qu'une seule application. Par contre GNOME est un composant. Tout comme ce qu'on surnomme LAMP (Linux Apache MySQL PHP).
Ce qui est intéressant, c'est que chaque composant garde une certaine indépendance par rapport aux autres composants. Ainsi le composant GNOME peut contenir différentes branches : 2.4, 2.6, 2.8. 2.4 peut être considéré comme rendu obsolète par la 2.6, donc on peut placer la branche 2.6 comme étant stable et testée. Contrairement à la branche 2.8 qui elle est encore peu testée et dont on ne sait si elle est au moins aussi stable que la précédente. Au moment de créer une distrib ou de faire un snapshot stable, on prendra donc GNOME 2.6 et non 2.8. Tout en pouvant, et ce sans aucune difficulté, continuer le développement des paquets de GNOME 2.8, tout en continuant d'améliorer les paquets de GNOME 2.6. Etc.
À noter que pour fonctionner le composant GNOME à effectivement besoin du composant XFree86 ou du composant X.org. Mais ceci n'intervient pas dans son développement. Et finalement que je choisisse GNOME 2.6 ou GNOME 2.8, je me moque de savoir quelle version ou quel serveur X il va y avoir derrière. Il en faut un, c'est tout.
Cest là que la notion de composant est vraiment intéressante. Car c'est là que va bloquer (bêtement j'en convient) le processus de développement classique de la Debian (unstable/testing/stable). Car si un paquet important du système de base vient à être totalement buggué et instable, c'est tout ce qui gravite autour qui morfle, et le cycle reste bloqué (cf. les longues périodes de non maj automatiques de Sarge qd la glibc ou gcc sont cassés ds Sid). Dans la version par composant on s'en moque, car le système ne tourne pas autour de cette version cassée, mais sous la version du composant qui va bien.
Nota: le but (aussi) de la Progeny Debian est d'améliorer les paquets de la Debian, afin que Sarge (par exemple) soit encore meilleure. En la rendant compatible LSB 2.0 par exemple. De plus la Progeny Debian n'est finalement pas autre chose qu'une Debian. Mais architecturée et pensée différemment (pas qu'une stabilité des paquets, mais aussi une expérience utilisateur et une configuration générale déjà paramétrée).
[^] # Re: le principe ? (désolé)
Posté par Julien Portalier . En réponse au journal Progeny Debian 2.0 beta 2. Évalué à 3.
Là on se retrouve avec des composants. À noter que FireFox n'est PAS un composant, mais un simple paquet, car il ne représente qu'une seule application. Par contre GNOME est un composant. Tout comme ce qu'on surnomme LAMP (Linux Apache MySQL PHP).
Ce qui est intéressant, c'est que chaque composant garde une certaine indépendance par rapport aux autres composants. Ainsi le composant GNOME peut contenir différentes branches : 2.4, 2.6, 2.8. 2.4 peut être considéré comme rendu obsolète par la 2.6, donc on peut placer la branche 2.6 comme étant stable et testée. Contrairement à la branche 2.8 qui elle est encore peu testée et dont on ne sait si elle est au moins aussi stable que la précédente. Au moment de créer une distrib ou de faire un snapshot stable, on prendra donc GNOME 2.6 et non 2.8. Tout en pouvant, et ce sans aucune difficulté, continuer le développement des paquets de GNOME 2.8, tout en continuant d'améliorer les paquets de GNOME 2.6. Etc.
À noter que pour fonctionner le composant GNOME à effectivement besoin du composant XFree86 ou du composant X.org. Mais ceci n'intervient pas dans son développement. Et finalement que je choisisse GNOME 2.6 ou GNOME 2.8, je me moque de savoir quelle version ou quel serveur X il va y avoir derrière. Il en faut un, c'est tout.
Cest là que la notion de composant est vraiment intéressante. Car c'est là que va bloquer (bêtement j'en convient) le processus de développement classique de la Debian (unstable/testing/stable). Car si un paquet important du système de base vient à être totalement buggué et instable, c'est tout ce qui gravite autour qui morfle, et le cycle reste bloqué (cf. les longues périodes de non maj automatiques de Sarge qd la glibc ou gcc sont cassés ds Sid). Dans la version par composant on s'en moque, car le système ne tourne pas autour de cette version cassée, mais sous la version du composant qui va bien.
Nota: le but (aussi) de la Progeny Debian est d'améliorer les paquets de la Debian, afin que Sarge (par exemple) soit encore meilleure. En la rendant compatible LSB 2.0 par exemple. De plus la Progeny Debian n'est finalement pas autre chose qu'une Debian. Mais architecturée et pensée différemment (pas qu'une stabilité des paquets, mais aussi une expérience utilisateur et une configuration générale déjà paramétrée).