À supposer qu'un dépôt "desktop" pour Debian stable fournisse les versions récentes des logiciels tiers (genre Pidgin 2.3.0, Wesnoth 1.2.8) sauf si ceux-ci demandent des versions trop récentes de bibliothèques système
Et encore on peut imaginer l'installation en parallèle d'une version plus récente d'une lib système problématique pour permettre de mettre à jour un programme qui le nécessiterait.
Il y a sûrement moyen de faire ça proprement :
Genre un paquet malib-1.0.2, celui stable et par défaut
un paquet malib-recente-1.0.3 qu'on voudrait ne pas mettre mais qu'on doit à cause de la grosse faille d'un bloatware dont on ne peut pas se passer comme un navigateur internet et qui impose de passer à la version 42 pour être corrigée..
Donc on a un paquet bloatware-41 qui a comme dépendance malib-1.0.2, et un paquet bloatware-42 qui a comme dépendance malib-recente-1.0.3.
Lorsqu'on met à jour bloatware-41 en bloatware-42 le gestionnaire de paquet supprime bloatware-41, ne supprime pas malib-1.0.2 parcequ'utilisée par d'autres programmes, et installe malib-recente-1.0.3 comme dépendance.
Ensuite si on met à jour la distrib et que ça remplace malib-1.0.2 par malib-1.0.3 ou plus récente, lorsqu'on installera bloatware-43 , ou bien bloatware-42.1 qui est bloatware-42 mais sur le dépot de la nouvelle mouture de la distrib, malib-recente-1.0.3 ne sera nécéssaire pour aucun paquet et sera proposée à la désinstallation.
C'est propre, ça marche, c'est faisable.
Personnellement ça m'est arrivé d'emerger sous gentoo un paquet en --noreplace pour avoir une autre version de la même lib pour installer un programme qui n'était pas inclut dans la distribution (par exemple). Lib je ne pouvais pas mettre à jour sans rien casser (genre un paquet masqué pour de très bonnes raisons).
Après quand j'en ai plus besoin il faut que j'unmerge le paquet concurrent en précisant la version, mais c'est propre et tout, faudrait juste le faire de manière automatisée pour régler le genre de problème évoqué ici.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Les distributions Linux sont inadaptées
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Desktop Linux : mission impossible ?. Évalué à 2.
Et encore on peut imaginer l'installation en parallèle d'une version plus récente d'une lib système problématique pour permettre de mettre à jour un programme qui le nécessiterait.
Il y a sûrement moyen de faire ça proprement :
Genre un paquet malib-1.0.2, celui stable et par défaut
un paquet malib-recente-1.0.3 qu'on voudrait ne pas mettre mais qu'on doit à cause de la grosse faille d'un bloatware dont on ne peut pas se passer comme un navigateur internet et qui impose de passer à la version 42 pour être corrigée..
Donc on a un paquet bloatware-41 qui a comme dépendance malib-1.0.2, et un paquet bloatware-42 qui a comme dépendance malib-recente-1.0.3.
Lorsqu'on met à jour bloatware-41 en bloatware-42 le gestionnaire de paquet supprime bloatware-41, ne supprime pas malib-1.0.2 parcequ'utilisée par d'autres programmes, et installe malib-recente-1.0.3 comme dépendance.
Ensuite si on met à jour la distrib et que ça remplace malib-1.0.2 par malib-1.0.3 ou plus récente, lorsqu'on installera bloatware-43 , ou bien bloatware-42.1 qui est bloatware-42 mais sur le dépot de la nouvelle mouture de la distrib, malib-recente-1.0.3 ne sera nécéssaire pour aucun paquet et sera proposée à la désinstallation.
C'est propre, ça marche, c'est faisable.
Personnellement ça m'est arrivé d'emerger sous gentoo un paquet en --noreplace pour avoir une autre version de la même lib pour installer un programme qui n'était pas inclut dans la distribution (par exemple). Lib je ne pouvais pas mettre à jour sans rien casser (genre un paquet masqué pour de très bonnes raisons).
Après quand j'en ai plus besoin il faut que j'unmerge le paquet concurrent en précisant la version, mais c'est propre et tout, faudrait juste le faire de manière automatisée pour régler le genre de problème évoqué ici.
ce commentaire est sous licence cc by 4 et précédentes