从源编译对已经安装的应用程序的影响


8

我使用Ubuntu 12.04。假设我已经package x从存储库(及其所有依赖项)安装了1.7版,但是我需要一些仅在1.8版中可用的功能,因此我下载了源tar并进行了编译:

./configure  
make  
make install
  • 这会覆盖现有的1.7二进制文件吗?
  • 如果现有二进制文件被覆盖,那么程序包管理器是否会反映新版本(1.8),并且package x将来可以由程序包管理器进行更新?
  • 如果package y具有package x 1.8- 依赖关系,将被满足吗?

我一直试图在网上找到一个很好的资源来解释这一点。如果您有任何建议,请让我知道。


如果您有意规避包管理器,什么人间使你认为它随后将识别安装什么?
沙杜尔

@Shadur从根本上可以归结为该问题的发生,即当您使用来从源代码安装软件时会发生什么make install。我认为从答案中可以很明显地看出,实际上所有事情都是将文件复制到安装前缀内的目录中(尽管事实证明,这可能是因为可能会放入一些配置文件,/etc而某些表示初始数据的可动态更改数据)某物的状态/var)。但是,如果您不清楚,我很乐意编辑我的答案以进行解释。
伊利亚·卡根

@EliahKagan在那儿,我主要是对Philip讲话。
沙杜尔

Answers:


12

绝大多数.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已编译的软件创建自己的软件包,然后从该软件包进行安装。然后,程序包管理器将知道发生了什么。创建自己需要的软件包(不需要在其他人的计算机上很好地工作)实际上并不难。(但我认为,这可能超出了您目前所措词的范围。)


感谢您的详细答复,它使很多概念变得清晰
Philip D'Rozario

5

从软件中心,使用APT命令(apt-getaptitude)或dpkg进行安装的软件包管理系统都知道。dpkg是低级软件包操作工具,APT和朋友是更高级别的工具,可以调用dpkg它们执行实际安装并处理依赖关系和软件包下载。

如果从源代码编译程序,则程序包管理器将不知道该程序。Linux上的约定是:很难跟踪情况并覆盖安装的痛苦是:

  • /bin/lib/sbin/usr被保留到包管理器;
  • 除此之外,这/usr/local是给系统管理员的-尊重那里的目录层次结构,但是您可以自己管理文件。

查看在Ubuntu 10.04中将vim / gvim升级到7.3的最佳方法?获取获取最新版本软件的方法列表。如果有PPA,最简单的方法是获取PPA。如果您获得二进制软件包或从源代码进行编译,建议您使用stow来管理手动安装的软件。或者,制作自己的.deb软件包 -这是更多的工作,但是如果您经常进行升级(通常为下一个次要版本重做该软件包非常快)或将其部署到运行相同发行版的多台计算机上,那么这是有回报的。

对于大多数程序,如果运行./configure && make && sudo make install,该程序将安装在下/usr/local。请检查来源随附的文档(通常在名为README或的文件中INSTALL),或者运行./configure --help以检查是否为这种情况。如果该程序安装在下/usr/local,则不会干扰程序包管理器提供的版本。/usr/local/bin首先在系统上PATH。注意,您需要以make install管理员(root)身份运行;不要以root身份编译。如上所述,我建议使用stow而不是直接安装到中/usr/local


1

这取决于包装和许多其他东西

  1. 使用的命名约定-二进制文件的文件名中是否包含版本号
  2. 安装位置-在opt中默认为它,但打包的版本在/ usr中
  3. 更多的可能性

长话短说:
没有通用的答案。它高度依赖于程序包。如果可能,您应该使用官方的+1 PPA,而不是从源代码进行编译。


1
从源代码编译的程序或库安装在中实际上是非常不寻常的/opt/usr/local是标准前缀,甚至/usr是比更为常见的默认前缀/opt/opt是最常用于安装在为特定应用程序命名的专用目录内的软件的软件(例如,可能安装了名为Foo的应用程序,其所有文件都位于其中/opt/foo)。
伊利亚·卡根
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.