Le terme de meta-paquet semble en effet plus approprie.
KDE s'est pose de nombreuse fois la question de diviser plus ses paquets facon Gnome, et a chaque fois rejete l'idee. Les arguments qui prevalent:
- avoir beaucoup de petits paquets rend la distribution de l'environnemnt complet plus penible, puisqu'il faut aller chercher manuellement 94 paquets.
- aujourd'hui, la bande passante est relativement bon marche, donc telecharger moins de paquets ne va pas faire une grosse difference. Dans la pratique, il est de plus tres probable que l'utilisateur selectif telecharge tous les paquets et ne les selectionne qu'au moment de la compilation/installation (ce qu'il peut faire de toute facon avec KDE)
- les dependances sont beaucoup beaucoup plus simples a gerer de cette facon. C'est une critique que Gnome endure depuis longtemps. Meme un developpeur moyen avait du mal a compiler Gnome avant Garnome.
- la compilation de l'ensemble est nettement simplifiee puisqu'on repose sur le classique (make -f makefile.dist; configure; make; make install). N'importe qui prenant un peu de temps peut compiler KDE a la main. On a vu des traducteurs inexperimentes le faire.
- on pourrait penser que KDE oblige a compiler tout un meta-paquet mais ce n'est pas le cas. D'une part, il existe une variable d'environnement ou une option du configure (peu documentee, certe) qui desactive la compilation de paquets designes, d'autre part, apres l'etape du configure, on peut simplement aller dans le repertoire de son choix et restreindre sa compilation/installation a ce repertoire. Donc, dans le cas d'une compilation/installation a la main, KDE offre le meme niveau de granularite que Gnome. Seule la version packagee differe.
- la fabrication des paquets pour rpm et deb pour un projet aussi gros et complexe que KDE ou Gnome est en general tres complexe. La simplification qu'apporte les meta-paquets devrait faciliter le travail de packageur (sauf si c'est un masochiste et qu'il recree a la main la granularite)
- la gestion des dependances entres petits paquets est aussi tres chiante a gerer pour les developpeurs.
La seule chose qu'on a donc pas avec ce systeme de packaging, c'est le choix pour les utilisateurs finaux de distributions packagees de choisir finement la liste des logiciels installes par les rpm (genre je veux kmail mais pas knode), choix legitime qui peut quand meme faire sourire certains( "putain, j'ai gagne 0.0000013 go (1.3 ko) de binaire sur mon disque de 30 Go, ca se fete!" )
Ah si, un autre truc chiant avec le systeme de KDE, c'est que c'est difficile de distribuer une application hors du framework du KDE. Genre je fais evoluer ktrucmuche qui fait partie de KDE, c'est pas facile de faire une release independante. Cela dit, ca se fait quand meme et il y a un outil dans KDE pour extraire des applictions.
> J'apporte ces précisions avant tout parce que vous ne pouvez vous
> empêcher quelque soit le prétexte de dénigrer Gnome :-)
Je ne m'en cache pas. Cela dit, j'essaie de le faire a chaque fois en tout honnetete, avec des arguments objectifs, en presentant une perspective historique, et en reconnaissant les faiblesses de KDE et les atouts de Gnome.
[^] # Re: Konstruct, essayer KDEdans votre répertoire
Posté par Philippe F (site web personnel) . En réponse à la dépêche Konstruct, essayez KDE dans votre répertoire. Évalué à 2.
KDE s'est pose de nombreuse fois la question de diviser plus ses paquets facon Gnome, et a chaque fois rejete l'idee. Les arguments qui prevalent:
- avoir beaucoup de petits paquets rend la distribution de l'environnemnt complet plus penible, puisqu'il faut aller chercher manuellement 94 paquets.
- aujourd'hui, la bande passante est relativement bon marche, donc telecharger moins de paquets ne va pas faire une grosse difference. Dans la pratique, il est de plus tres probable que l'utilisateur selectif telecharge tous les paquets et ne les selectionne qu'au moment de la compilation/installation (ce qu'il peut faire de toute facon avec KDE)
- les dependances sont beaucoup beaucoup plus simples a gerer de cette facon. C'est une critique que Gnome endure depuis longtemps. Meme un developpeur moyen avait du mal a compiler Gnome avant Garnome.
- la compilation de l'ensemble est nettement simplifiee puisqu'on repose sur le classique (make -f makefile.dist; configure; make; make install). N'importe qui prenant un peu de temps peut compiler KDE a la main. On a vu des traducteurs inexperimentes le faire.
- on pourrait penser que KDE oblige a compiler tout un meta-paquet mais ce n'est pas le cas. D'une part, il existe une variable d'environnement ou une option du configure (peu documentee, certe) qui desactive la compilation de paquets designes, d'autre part, apres l'etape du configure, on peut simplement aller dans le repertoire de son choix et restreindre sa compilation/installation a ce repertoire. Donc, dans le cas d'une compilation/installation a la main, KDE offre le meme niveau de granularite que Gnome. Seule la version packagee differe.
- la fabrication des paquets pour rpm et deb pour un projet aussi gros et complexe que KDE ou Gnome est en general tres complexe. La simplification qu'apporte les meta-paquets devrait faciliter le travail de packageur (sauf si c'est un masochiste et qu'il recree a la main la granularite)
- la gestion des dependances entres petits paquets est aussi tres chiante a gerer pour les developpeurs.
La seule chose qu'on a donc pas avec ce systeme de packaging, c'est le choix pour les utilisateurs finaux de distributions packagees de choisir finement la liste des logiciels installes par les rpm (genre je veux kmail mais pas knode), choix legitime qui peut quand meme faire sourire certains( "putain, j'ai gagne 0.0000013 go (1.3 ko) de binaire sur mon disque de 30 Go, ca se fete!" )
Ah si, un autre truc chiant avec le systeme de KDE, c'est que c'est difficile de distribuer une application hors du framework du KDE. Genre je fais evoluer ktrucmuche qui fait partie de KDE, c'est pas facile de faire une release independante. Cela dit, ca se fait quand meme et il y a un outil dans KDE pour extraire des applictions.
> J'apporte ces précisions avant tout parce que vous ne pouvez vous
> empêcher quelque soit le prétexte de dénigrer Gnome :-)
Je ne m'en cache pas. Cela dit, j'essaie de le faire a chaque fois en tout honnetete, avec des arguments objectifs, en presentant une perspective historique, et en reconnaissant les faiblesses de KDE et les atouts de Gnome.