Articles : Les politiques de sorties des grands projets Open Source
Posté par patrick_g (page perso, ). Modéré le 23 juillet 2004.
Il est peut-être intéressant de tenter une revue globale (avec les citations issues des sites web officiels) afin de d'analyser les diverses solutions adoptées et d'en présenter les forces et les faiblesses.
Regardons plus en détails les politiques de sortie de divers noyaux et systèmes (Linux, OpenBSD, FreeBSD, NetBSD), distributions GNU/Linux (Gentoo, Debian, Mandrake, Fedora, Slackware), gestionnaires de bureau et autres (GNOME, KDE, Mozilla).
![[fr]](../images/fr.png)
Changement de politique des sorties Mandrake (437 hits)-
Changement de politique des sorties Gentoo (391 hits)
-
Debian avec des sorties à périodicité fixe ? (425 hits)
> Lire la dépêche (22 commentaires, moyenne: 3,8).
Vous avez demandé le commentaire #451472.
Run by 
Cette page a été générée par Templeet en 0.0769s (dont 0.0082 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
au sujet des distributions
Pour moi, aucune des politiques de releases des distributions ne me satisfait. Je ne comprend pas pourquoi pour debian par exemple, il faudrait qu'on attende que tout les logiciels inclus dans la distribution soient "stable". En quoi le logiciel trucmuche pour faire mes comptes influencerait sur le fonctionnement du kernel au point de devoir tester des mois la distrib avec telles versions de logiciels pour en sortir une version stable ?
Se trouve le problème que malgré qu'on est une base stable (le kernel, X et les bureaux), il faille tout de même se taper des applications rapidement obsolètes car évoluant plus vite.
Pour moi, je considère qu'une distribution est stable quand seulement la base est stable, que tout les composants de bases fonctionne bien ensemble.
Pourquoi n'aurait-on pas par exemple dans Mandrake, la possiblité de mettre à jour les applications de "haut niveau" ? Pourquoi faudrait-il attendre 6 mois pour avoir une nouvelle version de la distribution afin d'avoir une mise à jour de la dernière version de Mozilla, Grisbi ou open-office etc . ? Serait-ce parce que les editeurs craignent que ça mette la stabilité du système en danger ? Ils ne font pas confiance aux équipes de développement qui produisent lesdits logiciels quand ils sortent une nouvelle version stable ? Ce n'est pas une raison suffisante pour les proposer en mise à jour ? Quelles autres raisons ? Je n'en vois pas.
En mettant à jour à la main ce genre d'application, je n'ai jamais rencontré de problème. L'appli XYZ en général n'en a strictement rien à foutre de la version du kernel ou de X ou de je ne sais quel autre logiciel de base. Par contre, c'est un problème pour l'utilisateur, parce que c'est chiant de mettre à jour à la main et qu'on ne peux pas profiter des facilités de Urpmi ou apt.
Je pense qu'une distribution devrait être coupée en deux : Il y aurait un repository des paquets des logiciels de base (kernel &co). Ce repository servirait de réference par rapport aux versions officielles de la distribution. Et un deuxième repository contenant les paquets des applications de plus haut niveau (les applis bureautiques, et autres), qui ne connait pas de versionning et dans lequel les applis seraient mis à jour régulièrement au fur et à mesure qu'elles sortent, que l'on pourrait donc mettre à jour sur son système avec apt ou urpmi ou équivalent sans avoir à attendre 6 mois ou plusieurs années avant d'en profiter.
Actuellement, si on veut utiliser les dernières versions des applis, il faut installer une cooker ou équivalente, dont la base est jugée instable (puisqu'en test et c'est normal). Bref, on a deux choix :
- Soit on se traine avec des vieilles applis obsolètes mais une base système stable. (donc on se traîne les éventuels bugs de ces vieilles applis pendant des mois)
- Soit on a les derniers versions des applis mais avec une base système instable.
Je trouve ça ridicule.
En tant qu'utilisateur, je veux pouvoir mettre à jour openoffice, mozilla, ou je ne sais qu'elle autre application "desktop" sans attendre 6 mois, sans avoir à tout reinstaller quand enfin une nouvelle version de la distrib sort, tout en profitant du système de mise à jour simple et efficace de ma distribution.
[^]Re: au sujet des distributions
Finalement, ce dont tu rêve, c'est d'une distribution *BSD, puisque c'est le principe général (en tout cas pour freebsd et netbsd) : Une base stable, avec des releases stable, mais néanmoins assez fréquentes, du fait de la "petite" taille de la base, et un système de port qui te permet d'installer des softs dans leur version courante facilement, et même de surcharger les softs de la base par des versions plus stables (tout en gardant celle de la base, au cas ou).
C'est pour ça que certaines personnes installent une slackware minimale pour aboir la base, et greffent dessus pkgsrc (le système de ports de netbsd, conçu pour être assez portable) pour installer les softs au dessus de cette base.
C'est une solution sympatique, mais bien sûr, tu perds la guarantie de cohérence que te donnent la plupart des distributions linux. Sous debian stable, si quelque chose ne marche pas, c'est a coups sûr de ta faute : tu as mal configuré quelque chose, ou mal compris la doc, alors que là, et bien, c'est peut être un bug de la version courante, ou une incompatibilité avec une lib, et les possibilités de merdoiement sont infinies
[^]Re: au sujet des distributions
> Finalement, ce dont tu rêve, c'est d'une distribution *BSD
Je reessairais d'en installer une à l'occasion alors :-)
[^]Re: au sujet des distributions
Moi j'ai installé un freebsd 5.2.1 hier ( apparement la branche 5-STABLE c'est pour bientot ) bah ca marche bien :)
\_o<~~~~
[^]Re: au sujet des distributions
Ou un peu comme le projet Componentized Linux, si on veut rester sur du Debian GNU/Linux:
http://platform.progeny.com/componentized/about.html(...)
[+] [^]Re: au sujet des distributions
C'est pour ça que certaines personnes installent une slackware minimale pour aboir la base, et greffent dessus pkgsrc
c'est pour ça que certaines personnes plus "fut-fut" installent une gentoo et utilisent emerge (qui a le meme principe que les vénérable ports de bsd, mais encore plus avancé)
[^]Re: au sujet des distributions
TU parles des gens "fut-fut" qui font tellemnt rien de leur vie qu'ils peuvent perdre deux jours plein à compiler leur Gentoo ??
[^]Re: au sujet des distributions
Oui, ben c'est pas tant la mort que ça, tu y fais tourner la nuit, ou pendant que t'es pas là et voilà...
Je peux te dire que c'est pas si contraignant par rapport à ce que ça apporte!
PS: J'en suis à 6 gentoo installées sur différents poste, et c'est devenu de loin ma distrib préférée, même si je laisse une chance aux autre ;)
Archetype Javascript Framework : Faites le côté client!
[^]Re: au sujet des distributions
«Je ne comprend pas pourquoi pour debian par exemple, il faudrait qu'on attende que tout les logiciels inclus dans la distribution soient "stable". En quoi le logiciel trucmuche pour faire mes comptes influencerait sur le fonctionnement du kernel au point de devoir tester des mois la distrib avec telles versions de logiciels pour en sortir une version stable ?»
Je pense que tu n'as pas compris le sens de la dénomination "stable" et "unstable" de Debian. Cette dénomination ne fait pas référence à la stabilité des logiciels, mais de leur packaging. Un logiciel peut être plein de bugs et néanmoins être inclus dans stable du moment que son paquet respecte les conditions nécessaires.
Utiliser une Debian stable ne te donne pas de garantie que ton système ne plantera pas, cela te donne une garantie (relative) que rien ne sera cassé lors d'une mise à jour, que les dépendances entre les paquets sont correctes, etc.
[^]Re: au sujet des distributions
Le principal critère pour qu'un logiciel passe en testing, puis en stable, c'est le nombre de bugs ouverts dans le système de gestion des bugs Debian.
Il y a donc deux solutions pour qu'un package passe :
- il est stable
- il n'a pas été testé ! ou en tout cas, pas assez.
[^]Re: au sujet des distributions
Je suis globalement d'accord, il reste un gros morceaux qui peut aussi être considéré comme devant pouvoir être mis à jour souvent : le support du matériel.
Et là, ça implique le noyau et X au moins... Pas très périphériques comme applications.
Pour Mandrake, je pensais que la comunity serait comme tu le dis, avec les applications bureautiques mises souvent à jour, mais c'est pas vraiment ça.
Par contre, les membres du club ont des packages récents mis à dispo.
Sinon, moins à la portée du premier venu, on peut aussi backporter des packages des versions de dev (recompiler les SRPMS de cooker pour Mandrake par ex).
Chez Debian, il y a des backports aussi (http://www.backports.org/(...)) et tout un tas de gens qui mettent à dispo des package (http://www.apt-get.org/(...))
En conclusion, je crois que le cas n'est pas simple.
PS:
Il y a peut-être une place à prendre pour une nouvelle distrib.
[^]Re: au sujet des distributions
Pour ton PS en fait ca existe déjà
L'inconvenient (majeur) c'est que c'est à partir de sources
Notament avec gentoo
La distribution qu'on develope à trois a aussi trois branche (devel testing et stable) (Accessoirement on essaye de gérer des binaires en même temps ca marche pas trop trop mal mais c'est pas trop ça quand même)
Et des distributions comme ça il doit y en avoir un certains nombre
Bref ça existe mais c'est pas pratique à utiliser (en général quand on veut ce genre de choses c'est pour un serveur et bon compiler sur un serveur c'est pas top)
[^]Re: au sujet des distributions
> (en général quand on veut ce genre de choses c'est
> pour un serveur et bon compiler sur un serveur c'est
> pas top)
Attention, ne pas croire qu'il y a besoin de compiler sur toutes les machines Gentoo. Y'a les paquets binaires officiels, les paquets binaires qu'on se fait à sa sauce sur d'autres machines plus adaptées du réseau, etc. Des serveurs Gentoo sans même un gcc installé, c'est parfaitement possible et courant.
[^]Re: au sujet des distributions
Et là, ça implique le noyau et X au moins... Pas très périphériques comme applications.
Pour le noyau, un changement de version ne devrait pas pertuber les applications, car les interfaces (système de fichier, accès au périphériques) sont à ma connaissance stables, et je n'ai d'ailleurs pas rencontré de problème en pratique. Reste les programmes gérant directement des modules noyau (iptables, ppp ..), mais il doivent être assez rares pour que ce soit gérable.
Pour X, on a justement un fonctionnement client/serveur, avec un protocol bien standard entre les deux. On devrait normalement pouvoir gérer séparement le serveur (avec les pilotes mis à jour) et les Xlibs coté clients.
Je pense en plus qu'avoir des "bases" stable facilerait le déploiement de Linux en entreprise, car une "configuration" donnée serait pereine quelques années, et les vendeurs/distributeurs d'applications pourrait fournir leurs programmes en était assuré de trouver cette base chez leur client.
L'idéal serait même d'avoir des "configurations de base" communes à plusieurs distributions. Les utilisateurs aurait le choix de la distrib, et les développeurs serait assurés de fournir un truc compatible.
[^]Re: au sujet des distributions
En tant qu'utilisateur, je veux pouvoir mettre à jour openoffice, mozilla, ou je ne sais qu'elle autre application "desktop" sans attendre 6 mois, sans avoir à tout reinstaller quand enfin une nouvelle version de la distrib sort, tout en profitant du système de mise à jour simple et efficace de ma distribution.
Une solution possible pour realiser ce que tu dis, c'est d'utiliser le fichier /etc/urpmi/skip.list
$ cat /etc/urpmi/skip.list
# Here you can specify the packages that won't be upgraded automatically
Et tu te fais 2 scripts, qui mettent dans ce fichier soit :
1/ La liste des packages de bases
2/ Le reste des packages
Ensuite tu passes en cooker, en commencant par mettre la premiere liste de packages (pour pas qu'ils soient mis a jour), et tu lances urpmi comme avant ...
J'avous que c'est crade, mais je pense que ca repond a ton besoin :)
J'imagine que le meme principe est faisable sous Debian ...
[^]Re: au sujet des distributions
> Ils ne font pas confiance aux équipes de développement qui produisent lesdits logiciels quand ils sortent une nouvelle version stable ? Ce n'est pas une raison suffisante pour les proposer en mise à jour ? Quelles autres raisons ? Je n'en vois pas.
Peut-être par manque de temps/argent ?
Faut faire le paquet, compiler, tester un minimum (problème de compatibilité), mettre sur les mirroirs, etc...
A celà s'ajoute tous les problèmes de dépendance... (les logiciels évoluent et leurs dépendances aussi), le problème d'audit du code, etc...
Bref, la complexité augmente en flèche.
Pour Fedora, il faut un mois de freeze complet (pas de changement de version et que des corrections de bugs) pour fiabiliser alors que les développeurs ne s'occupent que de ça. Pourtant il reste encore des problèmes lors de la release finale...
Monter en version un paquet se fait parfois sans accro. Ce n'est pas toujours le cas.