依赖关系和预先依赖关系有什么区别？
什么是“依赖”和“预先依赖”，以及我在Ubuntu中安装东西时这两种类型的包需求之间的区别？
从这个链接中可以看出： https ： //www.debian.org/doc/debian-policy/#document-ch-relationships
有5种类型的依赖项：
五个依赖字段的含义如下：
要看
-
这声明了绝对依赖。 除非已正确配置其“取消”字段中列出的所有包，否则不会配置包。 如果依赖包需要依赖的包来提供大量function，则应使用Depends字段。 如果postinst或prerm脚本要求解包或配置依赖的包以便运行，也应使用Depends字段。 在postinst配置的情况下，将首先解压缩并配置所依赖的包。
-
在prerm或其他postinst操作的情况下，包依赖性通常至少是解压缩的，但如果先前的依赖性升级失败，它们可能只是“半安装”。 最后，如果postrm脚本需要depen-on软件包在删除软件包后进行完全清理，则应使用Depends字段。 无法保证在运行postrm时可以使用包依赖项，但如果包声明了依赖项（特别是在postrm remove的情况下），则依赖的包更有可能可用。 如果该依赖项不可用，则postrm脚本必须优雅地跳过需要依赖项的操作。
建议
- 这声明了一个强大的，但不是绝对的依赖。 Recommends字段应列出在除了不寻常的安装之外的所有包中找到的包。
提示
- 这用于声明一个包对一个或多个其他包可能更有用。 使用此字段告诉包装系统和用户所列出的包与此相关，并且可能增强其实用性，但是安装这个包没有它们是完全合理的。
提高
- 此字段与Suggests类似，但工作方向相反。 它用于声明包可以增强另一个包的function。
预依赖
-
这个字段就像Depends一样，除了它还强制dpkg完成安装之前命名的软件包，甚至开始安装声明预依赖的软件包 ，它的工作原理是这样的，当一个包声明一个预依赖是什么时候如果已完全配置所依赖的包，或者即使所依赖的包仅被解包或处于“半配置”状态，只要它们已被配置，则可以解压缩预依赖性正确地在过去的某个时刻（并且从那以后没有删除或部分删除）。
-
在这种情况下，先前配置的和当前未解包的或“半配置”版本都必须满足Pre-Depends字段中的任何版本子句。 当声明要依赖于预依赖性的包时，预依赖性将被视为正常依赖。 只有在正确配置了依赖的包时，才会认为它是满意的。 但是，与Depends不同，Pre-Depends不允许破坏循环依赖。 如果在尝试遵循Pre-Depends时遇到循环依赖关系，则将中止安装。
-
如果preinst脚本依赖于命名包，则还需要预先取决于。 如果可能的话，最好避免这种情况。 应该谨慎使用Pre-Depends，最好只使用过早升级或安装会妨碍系统继续进行任何可能正在进行的升级的软件包。
较小的版本：
- 两者都取决于 预先依赖提及安装之前程序包所需的依赖项，但预先依赖强制依赖程序包的安装和配置，甚至在需要依赖项的程序包开始之前。 在处理完所有预先依赖的软件包之前，dpkg甚至不会解压缩主程序包。 使用depends，依赖包和主要包的顺序并不重要。 对于pre-depends，它会考虑到这一点以及validation预置包是否配置和安装。 如果没有这个，主包甚至不会被解压缩，配置或安装。 在开始使用主程序包的过程之前，您必须安装依赖项。 如果没有，则必须首先下载/配置/安装它们，然后再继续。 pre-depends通常用于包装的稳定性很重要并且不会以非常糟糕的方式影响系统或程序的情况，但是这种情况可以通过上面链接中提到的几个规范来避免。
术语“依赖”可以广泛地用于包括“取决于”和“取决于前”的关系（有时甚至是其他较弱的关系），或者它可以狭义地用作“取决于”的同义词。
“Depends”和“Pre-Depends”包关系之间的区别在于，如果X 依赖于Y，则必须在配置X之前完全配置Y. （配置是一个安装步骤，其中一个包，一旦将其文件解压缩到适当的位置 – 即，一旦“安装” – 进行任何其他必要的更改，以便可以实际使用它提供的软件。例如，HTTP服务器的配置可能涉及确保有一个具有适当能力的www用户和具有适当权限的/var/www目录。）相反，如果X 预先依赖于Y则必须安装Y并且（通常）完全在安装 X之前配置。
有关更多详细信息，请参见Debian Policy Manual的7.2节 。 我在这里引用了两个最相关的部分，但是该部分（以及更常见的第7章）中还有其他信息可以帮助阐明依赖关系的工作原理。
Depends这声明了绝对依赖。 除非已正确配置其
Depends字段中列出的所有包（除非存在如上所述的循环依赖关系），否则不会配置包。如果依赖包需要依赖的包来提供大量function，则应使用
Depends字段。如果
postinst或prerm脚本要求解包或配置依赖的包以便运行，也应使用Depends字段。 在postinst配置的情况下，将首先解压缩并配置所依赖的包。 （如果两个包都涉及依赖循环，这可能无法按预期工作;请参阅几段后面的解释。）在prerm或其他postinst操作的情况下，包依赖性通常至少是解压缩的，但它们可能是如果先前的依赖升级失败，则只能“半安装”。最后，如果
postrm脚本需要postrm-on软件包在删除软件包后进行完全清理，则应使用Depends字段。 无法保证在运行postrm时可以使用包依赖项，但如果包声明了依赖项（特别是在postrm remove的情况下），则依赖的包更有可能可用。 如果该依赖项不可用，则postrm脚本必须优雅地跳过需要依赖项的操作。
Pre-Depends这个字段就像
Depends一样，除了它还强制dpkg完成安装之前命名的软件包，甚至开始安装声明预依赖的软件包，如下所示：当声明预依赖性的包即将被解包时 ，如果依赖的包被完全配置， 或者即使依赖的包只被解包或在“一半”中，也可以满足预依赖性。 – 配置“状态，前提是它们在过去的某个时间点已正确配置（并且之后未被删除或部分删除）。 在这种情况下，先前配置的和当前未解包的或“半配置”版本都必须满足
Pre-Depends字段中的任何版本子句。当声明要依赖于预依赖性的包时，预依赖性将被视为正常
Depends。 只有在正确配置了依赖的包时，才会认为它是满意的。 但是，与Depends不同，Pre-Depends不允许破坏循环依赖。 如果在尝试遵循Pre-Depends遇到循环依赖关系，则将中止安装。如果
preinst脚本依赖于命名包，则还需要Pre-Depends。 如果可能的话，最好避免这种情况。应该谨慎使用
Pre-Depends，最好只使用过早升级或安装会妨碍系统继续进行任何可能正在进行的升级的软件包。在
debian-devel邮件列表上讨论之前，您不应该为包指定Pre-Depends条目，并且已达成共识。 请参见第3.5节中的依赖关系 。