C'est pourtant la première chose à laquelle j'ai pensé en lisant ton plaidoyer.
Le modèle de publication des BSD conviendrait à ce que tu sembles vouloir implémenter comme solution (et que Gentoo ne reprend pas) :
- une branche main pour le système de base ;
- une branche applicative pour les autres applications.
Le principal, selon moi, étant de définir clairement les frontières entre un logiciel qui doit faire partie du système de base et les applications qui pourront être mises à jour en suivant au plus près les mises à jour en amont.
Et pourtant, c'est là qu'on voit déjà les premiers problèmes se profiler : de nombreux projets fournissent à la fois des binaires exécutables et des bibliothèques partagées. Les bilbiothèques auront tendance à s'inscrire dans le système de base alors que les binaires pourront être vus comme des applications, à moins de les inclure dans le système de base mais on peut vite déborder et on en revient au modèle commun des distributions de Linux : tout le monde dans la même branche.
Prenons comme exemple le navigateur Firefox.
Sous Ubuntu Feisty, le paquet source produit plusieurs binaires :
- firefox ;
- firefox-libthai ;
- libnss-dev ;
- libnspr-dev ;
- firefox-gnome-support ;
- libnspr4 ;
- firefox-dom-inspector ;
- libnss3 ;
- firefox-dev ;
- firefox-dbg.
(j'occulte volontairement les paquets de transition).
On distingue déjà les paquets avec les suffixes « -dev » ou « -dbg » comme des paquets prévus pour le développement d'applications, donc normalement destinés aux développeurs.
Il reste donc pour les utilisateurs « lambda » :
- firefox ;
- firefox-libthai ;
- firefox-gnome-support ;
- libnspr4 ;
- firefox-dom-inspector ;
- libnss3.
Parmi ceux-ci, le préfixe « lib » permet de distinguer les paquets fournissant des bibliothèques partagées des autres paquets fournissant des fichiers normaux ou des binaires. Observons d'un peu plus près, les dépendances inverses de ces deux paquets :
$ apt-cache rdepends libnss3
libnss3
Reverse Depends:
libnss-dev
libcamel1.2-10
firefox
cman
libnss-dev
libcamel1.2-10
gaim
firefox
cman
libnss3-dev
gaim-encryption
$ apt-cache rdepends libnspr4
(plus ou moins pareil)
Comme on peut le constater, ces bibliothèques ne servent pas qu'à firefox mais également à d'autres logiciels, comme gaim mais aussi evolution. On peut considérer qu'il s'agisse d'autres applications mais si l'on met à jour firefox comme le voudrait la Mozilla Foundation, on devrait sans doute mettre à jour les autres applications dépendant des bibliothèques en question (par exemple si on passe de libnspr4 à libnspr5). Ce qui reviendrait à publier de nouveaux paquets binaires pour gaim ou evolution alors que ces derniers n'ont pas été mis à jour en amont. Cela pose déjà assez de problèmes dans les versions de développement des distributions comme Debian pour ne pas introduire de nouvelles versions sans consulter ses pairs pour ne pas essayer un tel modèle sur une version qu'on proclamerait « stable ». Si des utilisateurs veulent à tout prix la dernière version d'un logiciel, ils leur faura assumer le fait qu'ils ne sont plus des utilisateurs « lambda » mais des utilisateurs déjà initiés. Un utilisateur dit « lambda » ne demande pas une version spécifique d'un logiciel : l'exemple de Firefox est uniquement dû à la publicité dont il fait l'objet. Sinon, on en serait encore à une version 0.9.x mais c'est tellement moins vendeur que 1.0 ou 2.0...
[^] # Re: Parfois
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Les distributions linux nouvelle génération. Évalué à 4.
Le modèle de publication des BSD conviendrait à ce que tu sembles vouloir implémenter comme solution (et que Gentoo ne reprend pas) :
- une branche main pour le système de base ;
- une branche applicative pour les autres applications.
Le principal, selon moi, étant de définir clairement les frontières entre un logiciel qui doit faire partie du système de base et les applications qui pourront être mises à jour en suivant au plus près les mises à jour en amont.
Et pourtant, c'est là qu'on voit déjà les premiers problèmes se profiler : de nombreux projets fournissent à la fois des binaires exécutables et des bibliothèques partagées. Les bilbiothèques auront tendance à s'inscrire dans le système de base alors que les binaires pourront être vus comme des applications, à moins de les inclure dans le système de base mais on peut vite déborder et on en revient au modèle commun des distributions de Linux : tout le monde dans la même branche.
Prenons comme exemple le navigateur Firefox.
Sous Ubuntu Feisty, le paquet source produit plusieurs binaires :
- firefox ;
- firefox-libthai ;
- libnss-dev ;
- libnspr-dev ;
- firefox-gnome-support ;
- libnspr4 ;
- firefox-dom-inspector ;
- libnss3 ;
- firefox-dev ;
- firefox-dbg.
(j'occulte volontairement les paquets de transition).
On distingue déjà les paquets avec les suffixes « -dev » ou « -dbg » comme des paquets prévus pour le développement d'applications, donc normalement destinés aux développeurs.
Il reste donc pour les utilisateurs « lambda » :
- firefox ;
- firefox-libthai ;
- firefox-gnome-support ;
- libnspr4 ;
- firefox-dom-inspector ;
- libnss3.
Parmi ceux-ci, le préfixe « lib » permet de distinguer les paquets fournissant des bibliothèques partagées des autres paquets fournissant des fichiers normaux ou des binaires. Observons d'un peu plus près, les dépendances inverses de ces deux paquets :
$ apt-cache rdepends libnss3
libnss3
Reverse Depends:
libnss-dev
libcamel1.2-10
firefox
cman
libnss-dev
libcamel1.2-10
gaim
firefox
cman
libnss3-dev
gaim-encryption
$ apt-cache rdepends libnspr4
(plus ou moins pareil)
Comme on peut le constater, ces bibliothèques ne servent pas qu'à firefox mais également à d'autres logiciels, comme gaim mais aussi evolution. On peut considérer qu'il s'agisse d'autres applications mais si l'on met à jour firefox comme le voudrait la Mozilla Foundation, on devrait sans doute mettre à jour les autres applications dépendant des bibliothèques en question (par exemple si on passe de libnspr4 à libnspr5). Ce qui reviendrait à publier de nouveaux paquets binaires pour gaim ou evolution alors que ces derniers n'ont pas été mis à jour en amont. Cela pose déjà assez de problèmes dans les versions de développement des distributions comme Debian pour ne pas introduire de nouvelles versions sans consulter ses pairs pour ne pas essayer un tel modèle sur une version qu'on proclamerait « stable ». Si des utilisateurs veulent à tout prix la dernière version d'un logiciel, ils leur faura assumer le fait qu'ils ne sont plus des utilisateurs « lambda » mais des utilisateurs déjà initiés. Un utilisateur dit « lambda » ne demande pas une version spécifique d'un logiciel : l'exemple de Firefox est uniquement dû à la publicité dont il fait l'objet. Sinon, on en serait encore à une version 0.9.x mais c'est tellement moins vendeur que 1.0 ou 2.0...
http://packages.ubuntu.com/feisty/source/firefox