Si la version d'un paquet qui n'est pas dans apt source, c'est-à-dire que la version n'apparaît pas lorsque j'exécute apt-cache policy package
, est-il judicieux d'installer un fichier .deb de cette version? Je suppose qu'il y a des risques ici. Est-ce que de tels risques se produisent souvent? Les conséquences du risque sont-elles souvent grandes ou petites? Les risques sont-ils réversibles en désinstallant le package pour revenir à la normale?
Un exemple spécifique, je souhaite installer le fichier bluez_5.50-0ubuntu1_AMD64.deb au lieu de la version du mainteneur de package bluez_5.37-0ubuntu5.1_AMD64.deb. Est-ce que quelqu'un essaie ça? Est-ce que c'est bon?
Un fichier .deb provenant d'une source logicielle externe installée manuellement ne sera pas automatiquement mis à jour comme ce serait le cas s'il était installé à partir des référentiels Ubuntu par défaut ou d'un PPA.
Lorsqu'un fichier .deb est installé, ses dépendances manquantes sont également installées. Il peut y avoir problèmes de gestion des paquets provoqués par des dépendances conflictuelles d'un paquet .deb installé manuellement avec d'autres paquets installés à partir des référentiels Ubuntu par défaut.
Y a-t-il une raison de faire confiance à la source du fichier .deb que vous avez installée manuellement autant qu'aux paquets provenant des référentiels Ubuntu par défaut? Ce facteur en soi constituerait une raison suffisante pour que certaines personnes installent le fichier .deb sur une machine virtuelle, si cela est possible, afin de minimiser les conséquences négatives et/ou irréversibles possibles de l'installation d'un package non approuvé .
Il peut y avoir alternatives plus sûres pour installer un fichier .deb relativement peu fiable.
Contrairement aux packages apt, les packages de capture sont généralement mis à jour vers la dernière version. Un paquet logiciel enfichable est une bonne alternative à un fichier .deb installé manuellement relativement peu fiable s'il est disponible dans les référentiels Ubuntu par défaut.
Une autre alternative à l'installation d'un fichier .deb relativement peu fiable avec des autorisations root est de rechercher le code source du package et de le compiler en tant qu'utilisateur normal dans votre propre répertoire personnel. C'est une option compliquée, dont l'avantage est que, quand c'est fait correctement, c'est plus sûr que d'installer un paquet relativement peu fiable avec des permissions root.
Les résultats de rmadison bluez
montrent les versions bluez suivantes. Le paquet bluez contient des outils et des démons système pour l’utilisation de périphériques Bluetooth, mais il ne contient pas les pilotes requis pour tous les périphériques Bluetooth. Lorsque Bluetooth fonctionne mal, c'est généralement à cause d'un problème de pilote, pas à cause de bluez.
bluez | 4.98-2ubuntu7 | precise | source, AMD64, armel, armhf, i386, powerpc
bluez | 4.98-2ubuntu7.2 | precise-updates | source, AMD64, armel, armhf, i386, powerpc
bluez | 4.101-0ubuntu13 | trusty | source, AMD64, arm64, armhf, i386, powerpc, ppc64el
bluez | 4.101-0ubuntu13.3 | trusty-security | source, AMD64, arm64, armhf, i386, powerpc, ppc64el
bluez | 4.101-0ubuntu13.3 | trusty-updates | source, AMD64, arm64, armhf, i386, powerpc, ppc64el
bluez | 5.37-0ubuntu5 | xenial | source, AMD64, arm64, armhf, i386, powerpc, ppc64el, s390x
bluez | 5.37-0ubuntu5.1 | xenial-security | source, AMD64, arm64, armhf, i386, powerpc, ppc64el, s390x
bluez | 5.37-0ubuntu5.1 | xenial-updates | source, AMD64, arm64, armhf, i386, powerpc, ppc64el, s390x
bluez | 5.48-0ubuntu3 | bionic | source, AMD64, arm64, armhf, i386, ppc64el, s390x
bluez | 5.48-0ubuntu3.1 | bionic-updates | source, AMD64, arm64, armhf, i386, ppc64el, s390x
bluez | 5.50-0ubuntu1 | cosmic | source, AMD64, arm64, armhf, i386, ppc64el, s390x
bluez | 5.50-0ubuntu1 | disco | source, AMD64, arm64, armhf, i386, ppc64el, s390x