Il y a des applications qui évoluent assez vite, et il est dommage de changer tout le système de base juste pour elles. Scribus, Inkscape, Gimp, Krita, Blender, Ardour, Cinelerra, OOo, Ekiga, Wesnoth, Wormux, etc... Ce sont des logiciels important d'avoir à jour pour ceux qui en font un usage important, parfois professionnel.
Cherchez les deux intrus.
Plus sérieusement, j'aimerais bien que tu me dresses l'agenda de leurs publications respectives pour 2007 et 2008. Je pense qu'on verra qu'il n'y a qu'une version majeure par an, tout au plus. Un logiciel qui évolue trop souvent n'est pas forcément synonyme de stabilité.
Un graphiste pour être dans le coup devra suivre les évolutions des logiciels de graphisme, mais ne voudra pas forcément tout réinstaller, avec les prises de têtes qui risquent d'arriver, juste pour avoir les dernières versions. Ca peut être dangereux pour son activité professionnelle elle-même si sa machine est en vrac. Mais il est aussi dangereux de ne pas se former aux nouvelles capacités des outils.
Et si la dernière version de Gimp demande la dernière version de GTK+ ? Va-t-il falloir passer à la dernière version de Gnome parce que la dernière version de GTK+ a cassé une ABI ? Il y a bien sûr la compatibilité ascendante mais il arrive un moment où le passage à une version supérieure d'un logiciel, à plus forte raison pour une bibliothèque très utilisée, peut devenir un problème. Et comment fera l'utilisateur débutant pour s'en sortir, cas échéant ? Je suis d'accord que la plupart des applications peuvent se contenter d'une version des bibliothèques dont ils dépendent qui ne soit pas nécessairement la dernière mais, non seulement ce n'est pas toujours documenté, mais il faudrait veiller à les compiler contre les versions fournies par le système dit de base.
Avec 0install, en règle générale, on peut avoir en cache plusieurs versions de la même application (genre la version stable plus la version beta pour la tester), et on peut aussi interroger la base de données des paquets installés (dpkg, rpm, etc) pour se servir des bibliothèque du système, c'est plus souple sans faire doublon. D'où l'intérêt de créer des interfaces à partir de paquets backports pour que ça s'intègre bien (un bon script peut s'en occuper). Si tu n'aimes pas 0install, il y a les paquets backports tous nus.
Justement : il y a une source de paquets rétro-portés pour chaque distribution d'Ubuntu. Pour gutsy, cela donne gusty-backports.
Est-ce que cela résoudrait le problème ? À moitié car les logiciels qui ne sont pas fournis normalement par la distribution ne seront tout simplement pas disponibles. La finalité est toujours la même : il faut des personnes motivées et volontaires pour s'occuper des logiciels à mettre à disposition dans les distributions.
[^] # Re: Reprenons...
Posté par Raphaël SurcouF (site web personnel) . En réponse au journal Ubuntu a finit de manger son pain blanc ?. Évalué à 2.
Cherchez les deux intrus.
Plus sérieusement, j'aimerais bien que tu me dresses l'agenda de leurs publications respectives pour 2007 et 2008. Je pense qu'on verra qu'il n'y a qu'une version majeure par an, tout au plus. Un logiciel qui évolue trop souvent n'est pas forcément synonyme de stabilité.
Et si la dernière version de Gimp demande la dernière version de GTK+ ? Va-t-il falloir passer à la dernière version de Gnome parce que la dernière version de GTK+ a cassé une ABI ? Il y a bien sûr la compatibilité ascendante mais il arrive un moment où le passage à une version supérieure d'un logiciel, à plus forte raison pour une bibliothèque très utilisée, peut devenir un problème. Et comment fera l'utilisateur débutant pour s'en sortir, cas échéant ? Je suis d'accord que la plupart des applications peuvent se contenter d'une version des bibliothèques dont ils dépendent qui ne soit pas nécessairement la dernière mais, non seulement ce n'est pas toujours documenté, mais il faudrait veiller à les compiler contre les versions fournies par le système dit de base.
Justement : il y a une source de paquets rétro-portés pour chaque distribution d'Ubuntu. Pour gutsy, cela donne gusty-backports.
Est-ce que cela résoudrait le problème ? À moitié car les logiciels qui ne sont pas fournis normalement par la distribution ne seront tout simplement pas disponibles. La finalité est toujours la même : il faut des personnes motivées et volontaires pour s'occuper des logiciels à mettre à disposition dans les distributions.