绝大多数.deb
软件包(无论它们是否由官方存储库提供)都以prefix进行安装/usr
。
这意味着打算由用户运行的可执行文件进入/usr/bin
或/usr/sbin
(或者/usr/games
如果是游戏的话)进入,共享库进入/usr/lib
,平台无关的共享数据进入/usr/share
,头文件进入/usr/include
,自动安装的源代码进入/usr/src
。
一小部分软件包/
用作前缀。例如,bash
程序包将bash
可执行文件放入/bin
,而不是/usr/bin
。这是提供最基本的要素在单用户模式(如恢复模式)运行,并启动多用户模式(但请记住,这通常包括功能安装某些类型的网络共享包......万一/usr
是远程文件系统)。
一小部分.deb
软件包,大多数是使用Quickly创建的,在其中创建一个特定于软件包的文件夹/opt
,并将所有文件放在此处。除此之外,大多数时间/opt
是从不使用系统程序包管理器但不涉及从源代码进行编译的可执行安装程序中安装的软件所使用的位置。(例如,如果您安装诸如MATLAB之类的专有程序,则可能会将其放在中/opt
。)
与此相反,当您下载源存档(或从诸如Bazaar或git的版本控制系统中获取源代码),构建并安装它时,通常会安装到前缀/usr/local
(除非您告诉它这样做)除此以外)。这意味着您的可执行文件位于/usr/local/bin
,/usr/local/lib
或中/usr/local/games
,您的库位于/usr/local/lib
等等中。
对此有一些例外-默认情况下,某些程序会安装到/usr
前缀,因此会覆盖软件包中相同程序的安装.deb
。通常,可以通过运行./configure --prefix=/usr/local
而不是./configure
在构建它们时来防止此情况。我再次强调,通常这不是必需的。
(因此,对于您来说,将要构建的源代码并将其安装以供系统使用是非常有意义/usr/local/src
的,为此目的而存在。)
假设已安装打包版本,/usr
而从源安装的版本位于/usr/local
:
已安装软件包中的文件不会被覆盖。
通常,当您从命令行手动调用程序时,较新的版本将运行(假设/usr/local/bin
或在可执行文件的安装位置位于您的PATH
环境变量中,并出现在相应的/usr
-prefixed目录之前,例如/usr/bin
)。
但是,通过菜单或搜索创建和使启动器可用的启动器可能存在一些问题。此外,如果您已在不同位置安装了一个以上版本的库,则确定哪个软件将使用哪个版本可能会变得更加复杂。
如果您实际上并没有同时使用程序和库的两个版本,则通常应删除不使用的程序或库的版本,尽管在某些情况下,您可能希望安装软件包来满足依赖性。
但是,如果由于任何原因文件被覆盖(例如,如果源代码安装在/usr
而不是中/usr/local
):
- 程序包管理器对安装软件的更改一无所知。它将认为已安装旧版本。可能会导致严重问题。您应该避免这种情况。如果是这种情况,则应该从源代码(通常
sudo make uninstall
在目录中)中卸载所安装的软件,然后卸载提供被覆盖文件的一个或多个软件包(因为通过卸载已安装的版本将无法还原它们)来源)。然后重新安装您想要的任何版本。/usr/local/src/program-or-library-name
至于满足依赖关系:
如果某个.deb
软件包取决于您从源安装的软件,并且需要从源(或更高版本)安装的版本,则该软件包将无法成功安装。(或者,更准确地说,您可以“安装”它,但永远不会“配置”它,因此您将无法使用它。)依赖关系是通过安装软件包的版本来解决的,而不是通过安装包的版本来解决的。您实际拥有什么软件。
同样,即使您手动删除了由要安装的软件所依赖的软件包提供的文件,软件也将至少尝试完全安装。(通常不应出于任何目的利用它。基于虚假信息运行的程序包管理器几乎总是一件坏事。)
因此,如果找不到提供所需软件版本的软件包,则可能需要使用.deb
已编译的软件创建自己的软件包,然后从该软件包进行安装。然后,程序包管理器将知道发生了什么。创建自己需要的软件包(不需要在其他人的计算机上很好地工作)实际上并不难。(但我认为,这可能超出了您目前所措词的范围。)