如果某个软件包的版本不在 apt 源中,即运行时没有显示该版本apt-cache policy package
,那么安装此版本的 .deb 文件是否明智?我猜这里存在风险。这种风险经常发生吗?风险的后果通常是大还是小?是否可以通过卸载软件包来恢复正常来消除风险?
举个具体的例子,我想安装 bluez_5.50-0ubuntu1_amd64.deb 文件,而不是 bluez_5.37-0ubuntu5.1_amd64.deb 软件包维护者版本。有人试过吗?可以吗?
答案1
来自外部软件源的手动安装的 .deb 文件不会自动更新就像从默认的 Ubuntu 存储库或 PPA 安装一样。
当安装 .deb 文件时,其缺少的依赖项也会随之安装。可能会有包管理问题由于手动安装的 .deb 包与从默认 Ubuntu 存储库安装的其他包的依赖关系冲突而导致的。
是否有理由像信任默认 Ubuntu 存储库中的软件包一样信任手动安装的 .deb 文件的来源?这个因素本身就足以让一些人在虚拟机中安装 .deb 文件(如果可以的话),以尽量减少安装 .deb 文件可能带来的不利和/或不可逆转的后果。不受信任的包。
可能有更安全的替代品安装相对不受信任的 .deb 文件。
与 apt 软件包不同,snap 软件包通常会更新到最新版本。如果 Ubuntu 默认存储库中有 snap 软件包,那么它就是相对不受信任的手动安装 .deb 文件的良好替代品。
除了使用 root 权限安装相对不受信任的 .deb 文件之外,还有一种替代方法是跟踪软件包的源代码,并以普通用户身份在您自己的主目录中对其进行编译。这是一个复杂的选项,其优点是,如果操作正确,它比使用 root 权限安装相对不受信任的软件包更安全。
结果
rmadison bluez
显示以下 bluez 版本。bluez 软件包包含使用蓝牙设备的工具和系统守护程序,但不包含所有蓝牙设备所需的驱动程序。当蓝牙出现故障时,通常是由于驱动程序问题,而不是 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