> je pense que l'approche source, parceque justement les dépendances y sont un peu plus souples que celles des paquets binaires, facilite un peu le dynamisme au sein d'une branche stable.
Oui et non, mais non. C'est un problème de gestion de projet et pas de "contraintes techniques" spécifiques au distribution binaire.
Avec une distribution binaire classique, il y a une seule configuration et une seule possibilité => monté vers la dernière version, le dernier "snapshot". Ce qui compte c'est que la dernière version soit cohérente et que les scripts de mise à jours marchent. C'est tout.
Si tu n'as qu'un dépôt, il est trivial de garantir qu'il n'y aura pas de dépendances de cassés et que celui qui fait une mise à jour n'aura pas de problème (du moins avec les dépendances). En bricolant rapidement avec "rpm --justdb --noscripts ...." tu peux vérifier les dépendances pour plusieurs dépôt (par exemple Fedora Core + Fedora Extra + Fedora Extra non-US). De plus, il n'y a qu'un environnement de développement (paquet rpm *-devel) : le dernier c'est tout. Et non un environnement avec nptl, un autre avec python, l'autre sans, etc.
Ça c'est pour le côté "serveur". Celui qui fournit les logiciels. D'autres outils vont peut-être voir le jour avec le nouveau format de dépôt : http://linux.duke.edu/metadata(...)
Ce format a été adopté par FC3. FC va aussi adopté Mach qui s'occupera des dépendances sources (avec peut-être génération automatique des "BuildRequire", j'ai pas vérifié depuis longtemps mais mach est vraiment intéressant) et maintient l'environnement de développement.
Pour le côté client, si tu fais une mise à jours de FC1+Fextra1 vers FC3+Fextra3 (pour donner un exemple multi dépôt), avec yum/apt/update s'il y a des problèmes de dépendances l'installation de sera pas faite ! _Aucun_ paquet n'est mis à jour.
Impossible d'avoir quelque chose de cassé (côté dépendance) sans utiliser des méthodes brutales ("rpm --nodeps").
Là on voit un "big" problème pour Fedora. En effet, anaconda (l'installeur fedora) ne fait que FC1+Fextra1 vers FC3. Avec un peu de "skin" on peut fait ça avec yum.
Donc clairement, d'un point de vu technique, l'avantage est côté distribution binaire (+ un bon gestionnaire de paquet) pour avoir des mises à jours récentes (si on est pas à une semaine prêt évidemment). En fait, l'avantage est au distribution binaire mono-config :-)
La "tarre" de Gentoo sur ce point est d'être multi-config (c'est aussi son avantage).
Par contre, la "facilité" pour compiler permet d'avoir des paquets sources synchroniser avec l'évolution de la distribution et beaucoup testé. C'est un gros plus du moment qu'il y a suffisament d'utilisateurs qui est du coup aussi un testeur. S'il y a beaucoup d'utilisateurs, il y a moins de personnes qui tombent sur les bugs dû à l'évolution de la distribution et ça tient la route d'un point de vu utilisateur (qui n'a pas envis d'être principalement un testeur). Apparament, le nombre d'utilisateur est suffisant.
L'autre point faible des distributions binaires est qu'il faut souvent un binaire par version de distribution (FC1, FC2, etc...) et il faut un testeur "dédié" (au moins pour faire "manuellement" le paquet).
> tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés).
C'est un défaut et un avantage si tu y regardes de près. Tu montes en version que quand ça ne casse pas ton système.
> je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement.
Peut-être, mais tu finis toujours par être bloqué ou être dépendant des capacités de mise à jours. Si Gnome 3.0 sort et n'est pas compatible avec Gnome 2.x et n'as pas de mise à jours automatique des données, c'est dur dur (surtout avec les données des utilisateurs (configuration)).
Il y a le même problème pour Apache 1.3 vers Apache 2.0, etc.
Je crois que la "bonne" voie (apréciation personnelle), la plus souple (développement) et existante (logiciel récent) est la politique des petits bons (par exemple FC2 -> FC3).
Si tu compares Gentoo stable maintenant avec FC2, FC2 est en retard mais de pas beaucoup (si j'était méchant, je dirais que FC2 à Linux 2.6 contrairement à Gentoo). Après mise à jours vers FC3 (via yum par exemple (même s'il y a quelques points durs [*])) t'as un système stable (supporté) plus à jours que Gentoo. Certe, celui qui veut la dernière nouveauté qui est sorti la veille sera un peu grinceux car les développeurs seront concentrés principalement sur la nouvelle branche de développement.
La force de Gentoo n'est pas dans le niveau de mise à jours (même si fort respectable) mais dans la combinaison "souplesse de la configuration"/"niveau de mise à jour". Sur le point, elle met la pâté à tout le monde :-). Y a pas photo.
> C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA,
C'est là qu'on voit que ça ne marche pas dans la pratique :-)
Qu'il y a toujours un moment ou il faut une rupture. Sinon tu es englué dans des problèmes de compatibilité, de mise à jours etc...
[^] # Re: Qlqs compléments
Posté par 007 . En réponse au journal [Long] Expérience Gentoo. Évalué à 2.
Oui et non, mais non. C'est un problème de gestion de projet et pas de "contraintes techniques" spécifiques au distribution binaire.
Avec une distribution binaire classique, il y a une seule configuration et une seule possibilité => monté vers la dernière version, le dernier "snapshot". Ce qui compte c'est que la dernière version soit cohérente et que les scripts de mise à jours marchent. C'est tout.
Si tu n'as qu'un dépôt, il est trivial de garantir qu'il n'y aura pas de dépendances de cassés et que celui qui fait une mise à jour n'aura pas de problème (du moins avec les dépendances). En bricolant rapidement avec "rpm --justdb --noscripts ...." tu peux vérifier les dépendances pour plusieurs dépôt (par exemple Fedora Core + Fedora Extra + Fedora Extra non-US). De plus, il n'y a qu'un environnement de développement (paquet rpm *-devel) : le dernier c'est tout. Et non un environnement avec nptl, un autre avec python, l'autre sans, etc.
Ça c'est pour le côté "serveur". Celui qui fournit les logiciels. D'autres outils vont peut-être voir le jour avec le nouveau format de dépôt : http://linux.duke.edu/metadata(...)
Ce format a été adopté par FC3. FC va aussi adopté Mach qui s'occupera des dépendances sources (avec peut-être génération automatique des "BuildRequire", j'ai pas vérifié depuis longtemps mais mach est vraiment intéressant) et maintient l'environnement de développement.
Pour le côté client, si tu fais une mise à jours de FC1+Fextra1 vers FC3+Fextra3 (pour donner un exemple multi dépôt), avec yum/apt/update s'il y a des problèmes de dépendances l'installation de sera pas faite ! _Aucun_ paquet n'est mis à jour.
Impossible d'avoir quelque chose de cassé (côté dépendance) sans utiliser des méthodes brutales ("rpm --nodeps").
Là on voit un "big" problème pour Fedora. En effet, anaconda (l'installeur fedora) ne fait que FC1+Fextra1 vers FC3. Avec un peu de "skin" on peut fait ça avec yum.
Donc clairement, d'un point de vu technique, l'avantage est côté distribution binaire (+ un bon gestionnaire de paquet) pour avoir des mises à jours récentes (si on est pas à une semaine prêt évidemment). En fait, l'avantage est au distribution binaire mono-config :-)
La "tarre" de Gentoo sur ce point est d'être multi-config (c'est aussi son avantage).
L'avantage du source dans un contexte multi-config est ailleur il me semble. Je l'ai expliqué ici :
http://linuxfr.org/comments/488625,1.html(...)
Par contre, la "facilité" pour compiler permet d'avoir des paquets sources synchroniser avec l'évolution de la distribution et beaucoup testé. C'est un gros plus du moment qu'il y a suffisament d'utilisateurs qui est du coup aussi un testeur. S'il y a beaucoup d'utilisateurs, il y a moins de personnes qui tombent sur les bugs dû à l'évolution de la distribution et ça tient la route d'un point de vu utilisateur (qui n'a pas envis d'être principalement un testeur). Apparament, le nombre d'utilisateur est suffisant.
L'autre point faible des distributions binaires est qu'il faut souvent un binaire par version de distribution (FC1, FC2, etc...) et il faut un testeur "dédié" (au moins pour faire "manuellement" le paquet).
> tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés).
C'est un défaut et un avantage si tu y regardes de près. Tu montes en version que quand ça ne casse pas ton système.
> je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement.
Peut-être, mais tu finis toujours par être bloqué ou être dépendant des capacités de mise à jours. Si Gnome 3.0 sort et n'est pas compatible avec Gnome 2.x et n'as pas de mise à jours automatique des données, c'est dur dur (surtout avec les données des utilisateurs (configuration)).
Il y a le même problème pour Apache 1.3 vers Apache 2.0, etc.
Je crois que la "bonne" voie (apréciation personnelle), la plus souple (développement) et existante (logiciel récent) est la politique des petits bons (par exemple FC2 -> FC3).
Si tu compares Gentoo stable maintenant avec FC2, FC2 est en retard mais de pas beaucoup (si j'était méchant, je dirais que FC2 à Linux 2.6 contrairement à Gentoo). Après mise à jours vers FC3 (via yum par exemple (même s'il y a quelques points durs [*])) t'as un système stable (supporté) plus à jours que Gentoo. Certe, celui qui veut la dernière nouveauté qui est sorti la veille sera un peu grinceux car les développeurs seront concentrés principalement sur la nouvelle branche de développement.
La force de Gentoo n'est pas dans le niveau de mise à jours (même si fort respectable) mais dans la combinaison "souplesse de la configuration"/"niveau de mise à jour". Sur le point, elle met la pâté à tout le monde :-). Y a pas photo.
> C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA,
C'est là qu'on voit que ça ne marche pas dans la pratique :-)
Qu'il y a toujours un moment ou il faut une rupture. Sinon tu es englué dans des problèmes de compatibilité, de mise à jours etc...
[*] http://fedora.linux.duke.edu/FC3-rc1/3/i386/os/RELEASE-NOTES-en.htm(...)
Chercher "upgrade to udev using the following steps".