Pour moi ce sujet de synchronisation est important mais pas pour le proprio (enfin ce n'est pas l'aspect qui m'intéresse le plus, à eux d'essayer de suivre, pas au libre de s'adapter) ; la synchro est intéressante pour éviter de rater les échéances et courir derrière le noyau (notamment le noyau, mais il y a aussi côté applications).
Je préfère franchement l'approche de Fedora sur le sujet, prendre les travaux upstream du moment et les intégrer / traiter pour faire avancer.
Pour parler d'un sujet que je connais, Mandriva a choisi une approche intermédiaire sur le noyau, avec le paquet kernel-linus notamment, mais il est dépouillé des pilotes complémentaires et surtout présent àmha à des fins de tests (donc plutôt orienté cooker, même s'il peut servir sur une version stable).
J'ai en fait un peu l'impression que la stabilisation proposée par Andrew Morton (les .1, .2, .3) est sous-utilisée et que les distributions n'arrivent pas à "accrocher" sur le travail d'intégration qui était censé leur échoir.
Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
- en fait j'ai du matériel très bien supporté par ipw3945[1]
- les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
- Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
- cela fonctionne pas mal et permet de choisir celui qui fonctionne le mieux pour son matériel, mais ce n'est plus une distribution "monolithique" du noyau : cela en devient modulaire au niveau du packaging aussi
Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms ou le découpage des modules (bon là c'est pour l'instant une "exception"). Mais concrètement, cela permet d'utiliser dkms pour des pilotes libres et les recompiler "à la volée" ce qui me semble intéressant, évite de rebooter dans pas mal de cas vu qu'un modprobe -r est souvent suffisant (dkms à la base était plutôt vu pour nvidia ou ati par exemple, mais il peut tout à fait être utilisé pour du libre). Tout l'intérêt de dkms est de "gentoo-ifier" les modules : une recompil' et zou il remplace celui dans le kernel, c'est intéressant pour certains modules bien découplés du reste du kernel (l'exemple du wifi étant un peu biaisé vu qu'il y a des dépendances à d'autres modules tout de même mais ça le rend d'autant plus intéressant).
Bon je voulais parler de Gnome et KDE, mais pas forcément besoin : de ce que j'en vois, les versions de dév' -svn et rc sont assez bien suivies pour bénéficier dans la distrib' à sa sortie d'une version stable rapidement (dans les 2-3 jours de la release pour Gnome, voire le jour même pour KDE, Mandriva ayant les ressources sur le sujet). Pour KDE4, le choix pour la 2008.1 Spring a été de préserver les utilisateurs la version 4.0 étant plutôt pour les aventureux et les développeurs : l'install' dans /opt permet d'avoir les 2 en parallèle. Cela change pour la 2009.0 iirc.
Il y aurait les applications à traiter : je pense que c'est du côté des fermes de compilation que cela peut s'améliorer. OpenSuse a une ferme multi-distribution à ce que m'en disait un contributeur à Solutions Linux, cela pourrait être intéressant pour Mandriva et Fedora de regarder si ça marche vraiment (ça peut toujours faire un complément aux fermes disponibles en libre pour Fedora ou Mandriva). Cela permettrait d'avoir des dépôts "testing" mis à jour avec des versions -svn des applications par exemple (utilisable tant par cooker que 2008.1). Il me semble qu'Ubuntu propose de se construire ses propres paquets avec les PPA aka "personal packages archive" que Étienne Bersac avait présenté[3] succintement.
Cela pourrait être un moyen de répondre à la demande des utilisateurs et des développeurs upstream d'avoir des packages à jour (ou en tout cas de voir rapidement si le packaging "automatique" fonctionne encore ou doit être actualisé).
Ces fermes permettraient d'envisager aussi une recompilation massive, que ce soit pour un changement de gcc ou une option de compilation systématique. Cela a par exemple été fait pour Debian, cf.[4] mais il vaut mieux avoir du temps pour éplucher les logs d'erreur (il n'y a pas que la compilation qui prenne du temps).
Bref, voici quelques éléments qui peuvent servir à avancer àmha, sans prétendre être complet.
# synchro ou suivre ou avancer
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Je préfère franchement l'approche de Fedora sur le sujet, prendre les travaux upstream du moment et les intégrer / traiter pour faire avancer.
Pour parler d'un sujet que je connais, Mandriva a choisi une approche intermédiaire sur le noyau, avec le paquet kernel-linus notamment, mais il est dépouillé des pilotes complémentaires et surtout présent àmha à des fins de tests (donc plutôt orienté cooker, même s'il peut servir sur une version stable).
J'ai en fait un peu l'impression que la stabilisation proposée par Andrew Morton (les .1, .2, .3) est sous-utilisée et que les distributions n'arrivent pas à "accrocher" sur le travail d'intégration qui était censé leur échoir.
Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
- en fait j'ai du matériel très bien supporté par ipw3945[1]
- les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
- Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
- cela fonctionne pas mal et permet de choisir celui qui fonctionne le mieux pour son matériel, mais ce n'est plus une distribution "monolithique" du noyau : cela en devient modulaire au niveau du packaging aussi
Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms ou le découpage des modules (bon là c'est pour l'instant une "exception"). Mais concrètement, cela permet d'utiliser dkms pour des pilotes libres et les recompiler "à la volée" ce qui me semble intéressant, évite de rebooter dans pas mal de cas vu qu'un modprobe -r est souvent suffisant (dkms à la base était plutôt vu pour nvidia ou ati par exemple, mais il peut tout à fait être utilisé pour du libre). Tout l'intérêt de dkms est de "gentoo-ifier" les modules : une recompil' et zou il remplace celui dans le kernel, c'est intéressant pour certains modules bien découplés du reste du kernel (l'exemple du wifi étant un peu biaisé vu qu'il y a des dépendances à d'autres modules tout de même mais ça le rend d'autant plus intéressant).
Bon je voulais parler de Gnome et KDE, mais pas forcément besoin : de ce que j'en vois, les versions de dév' -svn et rc sont assez bien suivies pour bénéficier dans la distrib' à sa sortie d'une version stable rapidement (dans les 2-3 jours de la release pour Gnome, voire le jour même pour KDE, Mandriva ayant les ressources sur le sujet). Pour KDE4, le choix pour la 2008.1 Spring a été de préserver les utilisateurs la version 4.0 étant plutôt pour les aventureux et les développeurs : l'install' dans /opt permet d'avoir les 2 en parallèle. Cela change pour la 2009.0 iirc.
Il y aurait les applications à traiter : je pense que c'est du côté des fermes de compilation que cela peut s'améliorer. OpenSuse a une ferme multi-distribution à ce que m'en disait un contributeur à Solutions Linux, cela pourrait être intéressant pour Mandriva et Fedora de regarder si ça marche vraiment (ça peut toujours faire un complément aux fermes disponibles en libre pour Fedora ou Mandriva). Cela permettrait d'avoir des dépôts "testing" mis à jour avec des versions -svn des applications par exemple (utilisable tant par cooker que 2008.1). Il me semble qu'Ubuntu propose de se construire ses propres paquets avec les PPA aka "personal packages archive" que Étienne Bersac avait présenté[3] succintement.
Cela pourrait être un moyen de répondre à la demande des utilisateurs et des développeurs upstream d'avoir des packages à jour (ou en tout cas de voir rapidement si le packaging "automatique" fonctionne encore ou doit être actualisé).
Ces fermes permettraient d'envisager aussi une recompilation massive, que ce soit pour un changement de gcc ou une option de compilation systématique. Cela a par exemple été fait pour Debian, cf.[4] mais il vaut mieux avoir du temps pour éplucher les logs d'erreur (il n'y a pas que la compilation qui prenne du temps).
Bref, voici quelques éléments qui peuvent servir à avancer àmha, sans prétendre être complet.
[1] http://sophie.zarb.org/rpm/2008.1,x86_64/dkms-ipw3945 ancien pilote
[2] http://sophie.zarb.org/rpm/2008.1,x86_64/dkms-iwlwifi pilote plus récent + pile wifi
[3] https://linuxfr.org/~bersace/25359.html utilisation de ppa
[4] http://julien.danjou.info/blog/index.php/post/2007/08/16/Deb(...)