Vrftsjtryk

If a package's version that's not in apt source, i.e. the version not does not appear when I run apt-cache policy package, then is it wise to install a .deb file of this version? I guess there are risks here. Do such risks often happen? Are the risk's consequences often big or small? Are the risks reversible by uninstalling the package in order to go back to normal?

A specific example, I want to install the bluez_5.50-0ubuntu1_amd64.deb file instead of the bluez_5.37-0ubuntu5.1_amd64.deb package maintainer's version. Does anyone try this? Is it OK?

1. A .deb file from an external software source that is manually installed won't be automatically updated like it would be if it was installed from the default Ubuntu repositories or from a PPA.




2. When a .deb file is installed its missing dependencies are also installed along with it. There may be package management issues caused by conflicting dependencies of a manually installed .deb package with other packages that are installed from the default Ubuntu repositories.




3. Is there any reason to trust the source of the .deb file that you installed manually as much as you trust the packages from the default Ubuntu repositories? This factor by itself would be sufficient reason for some people to install the .deb file in a virtual machine if that's possible to do in order to minimize the possible adverse and/or irreversible consequences of installing an untrusted package.



4. 
   

   There may be safer alternatives to installing a relatively untrusted .deb file.

   
   
   
   
   

   • Unlike apt packages, snap packages are usually updated to the latest version. A snap package is a good alternative to a relatively untrusted manually installed .deb file if it is available in the default Ubuntu repositories.

   
   

   • Another alternative to installing a relatively untrusted .deb file with root permissions is to track down the source code of the package and compile it as a normal user in your own home directory. This is a complicated option, the advantage of which is when it's done properly it's safer than installing a relatively untrusted package with root permissions.

   
   
   • 
     

     The results of rmadison bluez show the following bluez versions. The bluez package contains tools and system daemons for using bluetooth devices, but it does not contain the required drivers for all bluetooth devices. When bluetooth is malfunctioning, it's usually because of a driver issue, not because of 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