Petit paquet, gros paquet, là est la question .
Bof...
Les gros paquets ? ni pour ni contre bien au contraire.
C'est pas la taille qui compte mais les dépendances.
Comme dit quelqu'un dont j'ai oublié le nom ce qui compte c'est de faire "the right thing". Faire ce qui convient. gnome-lib peut-être utilisé sans gnome-core alors pourquoi regrouper les deux ? glib peut-être utilisé sans gtk+ et est même de plus en plus utilisé pour des programmes sans interface graphique. Alors pourquoi imposer l'installation de Gtk+ pour n'utiliser que la partie glib. libxml (anciennement gnome-xml) est maintenant aussi utilisé par docbook-dtds. Pourquoi pour utiliser docbook, je devrais installer gnome ? libxml est aussi utilisé par kdebase. Tu serais heureux d'installer Gnome pour utiliser KDE ? De même, pango ne nécessite que glib. Peut-être qu'un jour KDE va utiliser pango. Si un jour tu as besoin pour x raisons d'installer deux fois la même librairie (par exemple pango 1.0 et pango 1.1) t'es pas obligé de mettre en doublon tout un tas de truc qui ne sert à rien.
Le fait de bien découpé un projet en librairies indépendantes facilite la réutilisation par d'autre projets et structure le projet. Si la librairie est réutilisée, elle ne devient pas une librairie spécifique Gnome par exemple, mais un librairie spécialisée dans son domaine où Gnome pioche dedans comme d'autres projets. Ainsi apprendre l'utilisation de libxml, glib ou pango n'est pas seulement un plus pour développer des applis Gnome, mais pour tout type d'applis qui ont besoin de ces fonctionnalités. La réutilisation par d'autres projets de ta librairie l'améliore car tu as le feedback de plein de développeurs.
KDE en regroupant tout, limite la réutilisation par d'autres projets. Ils créent des dépendances qui n'existe pas et donne une impression de "c'est tout ou rien".
> petits paquets:
> - une gestion lourde des dependances
C'est un faux problème. Les dépendances sont fixées une fois et c'est tout. Ce qui pose problème c'est lors des changements de librairie (style gtk qui forme un tout puis est splité en glib, gdk, gtk).
> - un travail plus lourd pour les empaqueteur du fait de la gestion des dependances entre plein de paquets
partiellement faux. Par exemple rpm c'est déterminer les dépendances entre librairies automatiquement.
> - un processus de recherche des bugs plus complexes
C'est clairement faux. Si tu as un programme qui ne marque plus suite à la mise à jour de plusieurs librairies, tu peux restaurer les anciennes librairies une par une pour trouver la fautive.
> oui mais j'ai le paquet X en v3.1 et Y en 0.4 avec Z en 0.2, est-ce que j'upgrage X pour faire marcher lambda ?
C'est le coût de la souplesse. Si j'installe gnucash 1.8 et qui me faut passer de libgal 0.18 à 0.19, je suis bien content de ne pas être obligé de mettre 10 autres librairies à jours qui peuvent compremettre le bon fonctionnement des programmes déjà installés.
> - une mise a jour beaucoup plus complexe, toujours a cause des dependances.
Y a des programmes pour çà.
> gros paquets:
> - une gestion de dependance hyper simple
Si tu gère plus les dépendances, c'est que les développeurs gère les dépendances... Car je crois pas qu'un développeur KDE qui bosse sur une partie spécifique peut être toujours synchrone avec le reste du projet. Déjà que pour des projets pas très gros il est fréquent de créer des branches spécifiques, je pense qu'il en est de même pour KDE.
[^] # Re: Gnome 2.2 est sorti
Posté par notrya2 . En réponse à la dépêche Gnome 2.2 est sorti. Évalué à 6.
Bof...
Les gros paquets ? ni pour ni contre bien au contraire.
C'est pas la taille qui compte mais les dépendances.
Comme dit quelqu'un dont j'ai oublié le nom ce qui compte c'est de faire "the right thing". Faire ce qui convient. gnome-lib peut-être utilisé sans gnome-core alors pourquoi regrouper les deux ? glib peut-être utilisé sans gtk+ et est même de plus en plus utilisé pour des programmes sans interface graphique. Alors pourquoi imposer l'installation de Gtk+ pour n'utiliser que la partie glib. libxml (anciennement gnome-xml) est maintenant aussi utilisé par docbook-dtds. Pourquoi pour utiliser docbook, je devrais installer gnome ? libxml est aussi utilisé par kdebase. Tu serais heureux d'installer Gnome pour utiliser KDE ? De même, pango ne nécessite que glib. Peut-être qu'un jour KDE va utiliser pango. Si un jour tu as besoin pour x raisons d'installer deux fois la même librairie (par exemple pango 1.0 et pango 1.1) t'es pas obligé de mettre en doublon tout un tas de truc qui ne sert à rien.
Le fait de bien découpé un projet en librairies indépendantes facilite la réutilisation par d'autre projets et structure le projet. Si la librairie est réutilisée, elle ne devient pas une librairie spécifique Gnome par exemple, mais un librairie spécialisée dans son domaine où Gnome pioche dedans comme d'autres projets. Ainsi apprendre l'utilisation de libxml, glib ou pango n'est pas seulement un plus pour développer des applis Gnome, mais pour tout type d'applis qui ont besoin de ces fonctionnalités. La réutilisation par d'autres projets de ta librairie l'améliore car tu as le feedback de plein de développeurs.
KDE en regroupant tout, limite la réutilisation par d'autres projets. Ils créent des dépendances qui n'existe pas et donne une impression de "c'est tout ou rien".
> petits paquets:
> - une gestion lourde des dependances
C'est un faux problème. Les dépendances sont fixées une fois et c'est tout. Ce qui pose problème c'est lors des changements de librairie (style gtk qui forme un tout puis est splité en glib, gdk, gtk).
> - un travail plus lourd pour les empaqueteur du fait de la gestion des dependances entre plein de paquets
partiellement faux. Par exemple rpm c'est déterminer les dépendances entre librairies automatiquement.
> - un processus de recherche des bugs plus complexes
C'est clairement faux. Si tu as un programme qui ne marque plus suite à la mise à jour de plusieurs librairies, tu peux restaurer les anciennes librairies une par une pour trouver la fautive.
> oui mais j'ai le paquet X en v3.1 et Y en 0.4 avec Z en 0.2, est-ce que j'upgrage X pour faire marcher lambda ?
C'est le coût de la souplesse. Si j'installe gnucash 1.8 et qui me faut passer de libgal 0.18 à 0.19, je suis bien content de ne pas être obligé de mettre 10 autres librairies à jours qui peuvent compremettre le bon fonctionnement des programmes déjà installés.
> - une mise a jour beaucoup plus complexe, toujours a cause des dependances.
Y a des programmes pour çà.
> gros paquets:
> - une gestion de dependance hyper simple
Si tu gère plus les dépendances, c'est que les développeurs gère les dépendances... Car je crois pas qu'un développeur KDE qui bosse sur une partie spécifique peut être toujours synchrone avec le reste du projet. Déjà que pour des projets pas très gros il est fréquent de créer des branches spécifiques, je pense qu'il en est de même pour KDE.