CN115934106A - 快速检测apt仓库源依赖完整性的方法 - Google Patents

Abstract

快速检测apt仓库源依赖完整性的方法，根据软件源中的资源建立一个索引文件，可以加快在软件源中查找软件包的速度。在Linux中使用刷新软件源的命令时，会扫描各软件源，并对各软件源所具有的软件包资源建立索引文件，存放在Linux操作系统本地。一种快速检测apt仓库源依赖完整性的方法就是利用操作系统本地的索引文件，对软件包的依赖完整性进行检测。本发明在检测软件依赖关系时，不需要提前构建所有软件包的依赖关系描述模型，直接利用软件源端的索引文件中对各软件包依赖关系的描述信息即可；本发明的功能重在检测，会返回导致依赖错误的具体原因，提高了软件包之间依赖关系的维护效率。

Description

快速检测apt仓库源依赖完整性的方法

技术领域

本发明涉及软件包依赖检测技术领域，具体涉及快速检测apt仓库源依赖完整性的方法。

背景技术

Linux的低成本、强大的定制功能以及良好的移植性能，使得Linux在嵌入式系统方面得到广泛应用。根据用户的不同需求，发布Linux操作系统的企业需同时开发众多定制的Linux操作系统，每种定制Linux操作系统又有众多的版本，且Linux操作系统又是由大量可安装的软件包组成的，这其中所包含的软件包之间有大量复杂的依赖关系需要检测。若在软件仓库源存在软件包的依赖错误，往往在安装软件包时才会被发现，需要解决这些错误才能交付该Linux操作系统，这会导致产品交付周期变长。若通过人工完成Linux操作系统软件包依赖关系的管理，软件包维护人员工作量、管理成本则会随着Linux操作系统和软件包规模不断增长，以及版本频繁的变更和更新而日益庞大。因此，如何快速有效地检测Linux操作系统软件包的依赖关系，提高企业发布Linux操作系统的效率显得尤为重要。

现有软件包依赖分析的方法包括基于集合分析、基于分层图分析等，其中效果较好的是分层图分析方法，其实现过程为：首先对指定操作系统的软件包构建分层图，针对某给定的软件，在图中查询其依赖关系，最后将相关关系进行导出。

 Linux操作系统中，软件包依赖关系也可以通过系统内置的命令进行查询，如“apt-cache show+软件包包名”，可以查询该软件包直接依赖的软件包的包名和版本信息。

基于分层图分析衍生出了一些软件包的检测方法，其步骤大致相同，首先基于软件依赖关系生成一张用于描述所有依赖关系的有向图，然后再输入软件包在图中节点的位置，从而对该软件包依赖路径上的各软件包的依赖关系是否满足进行判断检测。

Linux系统内置命令的方法，只能返回或检测软件包与软件包之间的直接依赖关系，而不能查询软件包的间接依赖关系；在Linux中，软件包之间可能有复杂的依赖链，例如，若软件包A依赖软件包B，软件包B又依赖于软件包C时，则软件包A间接地依赖软件包C。若要安装软件包A，则需要检查该依赖链上的每个软件包的依赖关系是否满足要求；因此单独返回、检测某一个软件包依赖的方法，效率低，需进行多步才能对某一软件包的依赖完整性进行检查与显示。

基于分层图的分析方法和基于分层图衍生的软件包检测方法，分别对所有软件包依赖关系构建图模型，再基于该关系图进行导出和检测。当部分软件包发生变化时，则需重新构建软件包依赖关系图，所需时间成本高，而若不及时更新软件包依赖关系图，则可能导致输出和检测的结果不准确，降低方法的精确度。其中，基于分层图的分析方法只显示软件包依赖关系，没有判断该依赖关系是否满足要求，也没有处理依赖问题的相应措施。因此，一旦出现依赖问题，该类方法不提供任何处理措施或处理建议。

因此，我们迫切需要一种能更全面检测特定软件包依赖关系的检测方法，旨在快速、高效、准确地检测某一软件包的依赖关系甚至整个Linux软件源仓库的依赖完整性是否满足。

中国发明专利“基于依赖的软件包依赖关系检查方法”（申请号CN201010241133X）、中国发明专利“一种软件包依赖关系检测方法”（申请号CN202111533240.4）和中国发明专利“一种Linux操作系统软件包依赖关系检测方法”（申请号CN201210324556.7），都提供了一种软件包依赖关系的检测方法，但是这些方法在检测软件包依赖之前，都要对所有软件包的依赖关系进行建模，只是使用不同的模型形式来表达所有软件包的依赖关系，利用这个模型来检测依赖关系，最后生成一个软件包的依赖关系的有向图。

发明内容

为解决已有技术存在的不足，本发明提供了一种快速检测apt仓库源依赖完整性的方法，包括如下步骤：

步骤S1：根据用户输入软件包的情况确定需要检测其依赖完整性的软件包，得到一个软件包列表packlist1；

步骤S2：遍历软件包列表packlist1，从软件包列表packlist1中按照顺序获取一个软件包package1，通过下述步骤判断软件包package1的依赖完整性；

步骤S3：判断软件包package1是否为虚包，若为虚包，则获取软件包package1的真实包名后再执行步骤S4，若不为虚包，则直接执行步骤S4；

步骤S4：获取软件包package1所直接依赖的软件包，得到一个软件包列表packlist Ⅰ；

步骤S5：判断软件包列表packlist Ⅰ是否为空，为空则说明软件包package1不依赖其它软件包，跳转至步骤S10或步骤S11，不为空则继续执行步骤S6；

步骤S6：判断软件包package1是否存在依赖冲突，若存在则结束整个流程并输出结果，若不存在，则继续执行步骤S7；

步骤S7：遍历软件包列表packlist Ⅰ，从中顺序获取一个软件包package Ⅰ，检测软件包候选版本的情况，若没有候选版本，则结束整个流程并输出结果，若有候选版本，则获取候选版本号并继续执行步骤S8；

步骤S8：判断候选版本号是否满足安装要求，若不满足安装要求，则结束整个流程并输出结果，若满足安装要求，则跳转至步骤S7继续顺序获取下一个软件包package Ⅱ，直至软件包列表中所有的软件包package Ⅰ、软件包package Ⅱ……均具备符合要求的候选版本；

步骤S9：递归跳转至步骤S2，按照步骤S2-步骤S8的方法，对软件包列表packlist Ⅰ中的软件包package Ⅰ、软件包package Ⅱ……的依赖完整性进行循环递归检查；

步骤S10：判断是否完成循环递归检查，若完成，则跳转至步骤S11；

步骤S11：跳转至步骤S2，从软件包列表packlist1中顺序获取软件包package2、软件包package3……，并依次完成其依赖完整性检测，直至遍历完软件包列表packlist1中的所有软件包，然后结束整个流程。

其中，所述步骤S1中，若用户输入了指定的软件包包名，仅检测传入的软件包的依赖完整性；若用户未输入软件包包名，则遍历软件源中所有的软件包，检查所有软件包的依赖完整性。

其中，所述步骤S6中，通过如下步骤判断某个软件包package是否存在依赖冲突：

步骤S61：获取该软件包package所依赖的软件包package-a、package-b……，得到该软件包的依赖链；

步骤S62：针对依赖链上的软件包package所依赖的每一个软件包package-a、package-b……，找出与其各自存在冲突关系的软件包，并判断与其各自存在冲突关系的软件包是否包括软件包package，若包括，则说明当前正在检测的软件包package存在依赖冲突，若不包括，则说明当前正在检测的软件包package不存在依赖冲突。

其中，所述步骤S61中，获取软件包package所依赖的软件包package-a、package-b……时，依赖关系包括Depends和Pre-Depends；

所述步骤S62中，针对依赖链上的软件包package所依赖的每一个软件包package-a、package-b……，找出与其各自存在冲突关系的软件包时，冲突关系包括break和conflicts。

其中，所述步骤S7中，通过如下方法获取软件包的候选版本号：找出软件包所隶属的所有软件源，将软件源按照优先级排序，以优先级最高的软件源中的该软件包的版本号作为该软件包的候选版本号；

若软件包所隶属的所有软件源优先级相同，则以该软件包在各软件源的最高版本号作为候选版本号；

若优先级最高的软件源中的该软件包对应有多个版本号，则以多个版本号中最高的版本号作为该软件包的候选版本号。

其中，所述步骤S5中，针对第一层软件包，若所获取的其直接依赖的软件包列表为空，则跳转至步骤S11，直接遍历下一个软件包；针对第一层软件包依赖链上的第二层之后的软件包，若所获取的其直接依赖的软件包列表为空，则跳转至步骤S10，判断该软件包所处的递归周期中所涉及到的其它软件包是否均已完成依赖完整性检测。

本发明在检测软件依赖关系时，不需要提前构建所有软件包的依赖关系描述模型，直接利用软件源端的索引文件中对各软件包依赖关系的描述信息即可；本发明的功能重在检测，会返回导致依赖错误的具体原因，提高了软件包之间依赖关系的维护效率。

附图说明

图1：本发明的快速检测apt仓库源依赖完整性的方法的实现流程图。

图2：本发明的一实施例中某个软件包的依赖链示意图。

具体实施方式

为了对本发明的技术方案及有益效果有更进一步的了解，下面结合附图详细说明本发明的技术方案及其产生的有益效果。

针对已有技术的缺陷，本发明所要解决的问题是，如何对Linux软件仓库源端的软件包依赖完整性进行检测，使其能够判定Linux某个软件包或整个软件仓库源中所有的软件包的可安装问题。本发明提出一种快速检测软件仓库源软件包依赖完整性的方法，旨在减少Linux系统中安装软件包出现依赖错误的几率，缩短产品交付周期，减小软件仓库维护工作的难度，提高软件仓库源中软件包管理的自动化程度。

Linux中采用集中式的软件仓库机制，将各种软件包分别存放在软件仓库中，进行有效地组织和管理。然后，将软件仓库放置不同的镜像服务器中，并保持基本一致。这些软件仓库就是所谓的软件源（Reposity）。

根据软件源中的资源建立一个索引文件，可以加快在软件源中查找软件包的速度。在Linux中使用刷新软件源的命令时，会扫描各软件源，并对各软件源所具有的软件包资源建立索引文件，存放在Linux操作系统本地。一种快速检测apt仓库源依赖完整性的方法就是利用操作系统本地的索引文件，对软件包的依赖完整性进行检测。

总体思路如下：根据软件源端的索引文件，首先检查与一个软件包有直接和间接依赖关系(依赖关系指的是Depends和Pre-Depends这两种)的软件包是否存在依赖冲突，若有冲突则输出有冲突的两个软件包包名，若没有冲突则找到与该软件包具有Depends和Pre-Depends依赖关系的所有软件包(这里的依赖关系是指直接依赖)，然后再递归查询这些软件包的候选版本是否满足软件包安装要求以及检查这些软件包的安装依赖是否满足要求，若有不符合要求的软件包，则输出出错的具体原因，给出解决错误的建议。

为更好地理解本发明的详细的实现细节，以下为一些相关的概念：

1、软件包间的关系

软件包之间的关系分为两类：依赖和冲突。若安装软件包x时，须先安装软件包y，则称x对y存在依赖关系；若软件包x和y无法同时存在，则x和y之间为冲突关系。

2、虚包

虚包是指一组具有相似功能的软件统称，虚包没有版本号。

3、Linux中依赖及冲突关系的分类（仅介绍本发明所涉及到的）

Depends关系：如果软件包X与软件包Y之间存在依赖关系，这意味着软件包X不能在缺少软件包Y的情况下运行。

Pre-Depends关系：属于安装时依赖。如果软件包Y与软件包X有Pre-Depends关系，表明在安装软件包Y时需要软件包X的支持。

Conflicts关系：表示软件包间的冲突关系。如果软件包X与软件包Y冲突，则软件包X与软件包Y不能在同一系统中共存，系统将拒绝允许软件包X与Y同时在系统上解压缩，相比于Breaks关系Conflicts表示更强的限制。

Break关系：与Conflicts关系相似，若一个软件包X的break关系中包含软件包Y，则表示软件包X的安装会将软件包Y（或者是特定版本）中断掉，则系统将拒绝允许软件包X被解包。

4、软件包的候选版本

软件包的候选版本即为Linux中安装软件包时系统默认的软件版本。

Linux软件包管理工具(Advanced Packaging Tool,apt)：是一个命令行实用程序，用于在Ubuntu、Debian和相关Linux发行版上安装、更新、删除和管理软件包。

如图1所示，为本发明提出的一种快速检测apt仓库源依赖完整性的方法的流程图，包括以下步骤：

步骤1：接收用户输入的软件包，根据传入的软件包是否为空来确定需要检测依赖完整性的软件包列表packlist1；

本发明有两种使用情景：其一，当输入了指定的软件包包名时，只会检测传入的软件包的依赖完整性；（这种情形对应“传入的软件包不为空”）其二，若未输入软件包包名，则会遍历软件源中所有的软件包，检查所有软件包的依赖是否完整（这种情形对应“传入的软件包为空”）。

步骤2：遍历软件包列表packlist1，对每个输入的软件包遍历检测该包所依赖软件包是否存在依赖冲突以及软件包的版本号是否满足要求；

2-1：从软件包列表packlist1中顺序获取一个软件包，记为package1，对package1进行依赖完整性检测；

2-2：判断package1是否为虚包，若package1为虚包，则获取package1真实的包名后，再进入2-3；若package1不为虚包，则进入2-3；

2-3：获取与软件包package1有Depends和Pre-Depends依赖关系的软件包(这里指的是与package1有直接依赖关系的软件包)，记为软件包列表packlist Ⅰ；

Linux中，索引文件会记录当前软件源中所有的软件包列表，包括各软件包的版本、依赖、描述等信息，可利用索引文件快速查找与某一软件包具有依赖关系的其他软件包，而且索引文件的包列表会根据软件源的最新结构进行实时更新，保证了软件包依赖关系的准确性。

2-4：判断软件包列表packlist Ⅰ是否为空，若为空则说明package1不依赖其他软件包，转至2-9或2-10（具体转到2-9还是2-10将于下文详述）；若不为空则说明package1还依赖其他软件包，进入2-5。

2-5：判断软件包package1是否存在依赖冲突，若存在依赖冲突则结束整个流程，跳至步骤3，输出“软件包存在依赖冲突”的错误；若不存在依赖冲突，则进入2-6；

要判断软件包package1是否存在依赖冲突，首先要检查package1依赖链上所涉及到的其它软件包，与其有conflicts和break依赖关系的软件包列表中是否包含package1，若存在某一个软件包的conflicts或break包列表中包含了package1，则说明在这一条软件包依赖链上，该包与package1存在冲突，导致整个软件包依赖链不成立，需输出软件包依赖存在冲突的错误信息；否则，说明该依赖链上，所有软件包的依赖关系都满足，依赖链成立。请结合图2所示：例如，软件包package1依赖软件包package Ⅰ和package Ⅱ，软件包package Ⅰ依赖软件包package-a和package-b(这里的依赖指的是Depends和Pre-Depends这两种依赖关系，且package1与package Ⅰ和package Ⅱ，package Ⅰ与package-a和package-b之间为直接依赖关系)，则package1 -> package Ⅰ-> package-a为软件包package1所在的一条依赖链，若软件包package Ⅰ或者软件包package-a的break或conflicts包列表中有package1，那么存在依赖冲突错误，依赖链package1 -> package Ⅰ-> package-a不成立；依赖链package1-> package Ⅰ-> package-b及依赖链package1 -> package Ⅱ可做同样的理解；

2-6：若软件包列表packlist Ⅰ不为空，则从软件包列表packlist Ⅰ中顺序获取一个软件包，记为package Ⅰ，对软件包package Ⅰ候选版本进行检测；

2-7：检查软件包package Ⅰ是否有候选版本，若没有则结束整个流程，跳至步骤3，输出“不存在候选版本”的错误；若有候选版本，则进入2-8；

2-8：检查软件包package Ⅰ候选版本的版本号是否满足其安装要求，若不满足安装要求，则跳至步骤3，输出“候选版本号不满足安装要求”的错误；若满足，则顺序获取下一个下一个软件包package Ⅱ，直至软件包列表中所有的软件包package Ⅰ、软件包package Ⅱ……均具备符合要求的候选版本；

2-9：跳转至步骤2-1，调用依赖完整性检测方法递归检测当前软件包列表packlist Ⅰ中所有软件包的依赖完整性，直至针对软件包package1所处的递归周期中所涉及到的所有软件包完成依赖完整性检测。

也即，针对软件包列表packlist Ⅰ，重新从步骤2-1开始，检查packlist Ⅰ列表中所有软件包的依赖完整性，这是一个递归循环的过程，直至针对软件包列表packlist Ⅰ所直接依赖的所有的软件包也均完成了依赖完整性检测，递归流程结束的条件是针对软件包package1所对应的所有依赖链所形成的依赖网上的软件包均完成了依赖完整性检测。

仍以图2为例：软件包package1依赖软件包package Ⅰ和软件包package Ⅱ，而软件包package Ⅰ依赖软件包package-a和软件包package-b，（为方便表述，分别以第一层、第二层及第三层代表软件包package1、软件包package Ⅰ和软件包package Ⅱ、以及软件包package-a和软件包package-b的层级），假设软件包package Ⅱ、软件包package-a和软件包package-b为基础软件包，基础软件包没有依赖的软件包，那么，在对软件包package1的依赖完整性检测时，经过虚包、依赖冲突判断后，从其所依赖的软件包列表packlist Ⅰ中先后获取软件包package Ⅰ和软件包package Ⅱ，这两个软件包均存在符合要求的候选版本，那么此时，针对软件包列表packlist Ⅰ，跳转至步骤2-1，顺序遍历其中的软件包的依赖完整性，首先遍历第一个软件包package Ⅰ，该软件包package Ⅰ依赖软件包package-a和软件包package-b，经过虚包和冲突检测（不存在依赖冲突）后，再顺序检测软件包package-a和软件包package-b的候选版本，经检测，软件包package-a和软件包package-b的候选版本均存在符合要求的候选版本，那么此时再将软件包package-a和软件包package-b形成一个新的列表，重新跳转至步骤2-1中，顺序检测软件包package-a和软件包package-b的依赖完整性，由于软件包package-a和软件包package-b均为基础包，没有依赖的软件包，到了步骤2-4的时候，得到一个空的列表，之后再跳转到步骤2-9中，当软件包package-a和软件包package-b均走完步骤2-1至步骤2-4，以及步骤2-9的时候，针对软件包package-a和软件包package-b所隶属的软件包列表，尽管当前所在层级的列表已遍历结束，但是，由于软件包package-a和软件包package-b属于第三层级，其本身局限在第一层软件包的依赖完整性检测中，所以遍历结束后还要检查其所处的递归周期（该递归周期涉及图2所示的第一层软件包package1所对应的完整的依赖网）是否结束。

因此，具体判断原则是针对当前已经遍历结束的软件包package-a和软件包package-b所处的依赖网的上一级的软件包package Ⅰ，判断是否有与其同级的软件包未完成依赖完整性检测），经检查，在第一层软件包package1的依赖网中，还有第二层软件包package Ⅱ未进行依赖完整性检测，那么此时则回到步骤2-1，遍历第二层的第二个软件包package Ⅱ，如此循环往复，直至这个递归周期中第一层软件包package1所有的直接或间接依赖的软件包均完成了依赖完整性检测，则针对第一层软件包package1的递归周期结束。

也就是说，在步骤2-4中，针对某一个软件包，当获取到的其所依赖的软件包列表为空时（即这个软件包属于基础软件包），如果这个软件包属于第一层级的软件包，则直接转到步骤2-10，遍历第一层级的下一个软件包；如果这个软件包不属于第一层级，而属于第一层级软件包对应的依赖网上，则需要转到步骤2-9，看下其所隶属的这个依赖网上的第一层级软件包所依赖的其它软件包是否都完成了依赖完整性检测，只有都完成了，才可以跳脱当前的递归周期，跳转至步骤2-10，从第一层级中遍历下一个软件包。

另外，针对软件包的候选版本号，本发明将两种策略，优先软件源策略及优先软件包版本号策略相结合，具体的：找出软件包所隶属的所有软件源，将软件源按照优先级排序，以优先级最高的软件源中的该软件包的版本号作为该软件包的候选版本号（若所有软件源优先级相同，则以该软件包在各软件源的最高版本号作为候选版本号）；若优先级最高的软件源中的该软件包对应有多个版本号，则以多个版本号中最高的版本号作为该软件包的候选版本号。

软件包依赖关系的表达：软件包的依赖关系经常会限制其所依赖的版本。如果软件包package1依赖于package Ⅰ(＞＝2.4.2)，表明软件包package1依赖于package Ⅰ，而且package Ⅰ的版本必须是大于或等于2.4.2的。

软件包的版本号比较关系一共有五种：＝完全相等；＜＝小于或等于；＞＝大于或等于；＜小于；＞大于。

2-10：判断软件包列表packlist1中软件包的依赖完整性是否全部检测完毕，若全部检测完，则进入步骤3；否则则跳至2-1，继续获取下一个软件包package2、package3……，直至完成所有软件包的依赖完整性检测；

步骤3：输出检测的结果；当列表packlist1中所有软件包的依赖完整性全都满足时，本发明不会输出结果；只有当某一软件包依赖完整性不满足时，才会输出错误信息。

本发明的错误信息有三种：其一，因软件包之间存在依赖冲突而输出的错误信息，"There is a dependency conflict between package1_name and package2_name"；其二，因软件包不存在候选版本而输出的错误信息，"no candidate package forpackage1_name"；其三，因软件包候选版本的版本号不满足其安装条件而输出的错误信息，"candidate package candidate1_name candidate1_version not satisfyrequirements package1_comp package1_target_version"。package1_name代表软件包1的包名称；package2_name代表软件包2的包名称；candidate1_name代表软件包1候选版本的名称；candidate1_version代表软件包1候选版本的版本号；package1_comp代表软件包1依赖的依赖关系表达(见步骤2-9中软件包版本号的五种比较关系)；package1_target_version代表软件包1依赖的版本号。

借上述总体技术方案，本发明一种快速检测apt仓库源依赖完整性的方法有下列优点及有益效果：

1、本发明基于软件源的索引文件对软件包的依赖进行检测，索引文件由软件仓库端产生，无需再对软件包直接的索引关系进行建模，节省了时间；软件源的索引文件内容会随着仓库软件包的变化随时更新，因此本发明检测软件包依赖关系的效果更为准确；

2、本发明通过递归检测软件包的所有直接依赖和间接依赖软件包是否满足安装要求，保证了所检测软件包的可安装性，降低安装软件包因依赖而导致的出错风险；

3、本发明中输出的检测结果的三种提示信息中，包含出问题的软件包名称、出问题的原因以及依赖版本号等信息，准确的描述了依赖不完整的原因，能使维护人员快速地找到出现问题的原因所在，提升了软件依赖维护的效率。

虽然本发明已利用上述较佳实施例进行说明，然其并非用以限定本发明的保护范围，任何本领域技术人员在不脱离本发明的精神和范围之内，相对上述实施例进行各种变动与修改仍属本发明所保护的范围，因此本发明的保护范围以权利要求书所界定的为准。

Claims (6)

1.快速检测apt仓库源依赖完整性的方法，其特征在于，包括如下步骤：

步骤S1：根据用户输入软件包的情况确定需要检测其依赖完整性的软件包，得到一个软件包列表packlist1；

步骤S2：遍历软件包列表packlist1，从软件包列表packlist1中按照顺序获取一个软件包package1，通过下述步骤判断软件包package1的依赖完整性；

步骤S3：判断软件包package1是否为虚包，若为虚包，则获取软件包package1的真实包名后再执行步骤S4，若不为虚包，则直接执行步骤S4；

步骤S4：获取软件包package1所直接依赖的软件包，得到一个软件包列表packlistⅠ；

步骤S5：判断软件包列表packlistⅠ是否为空，为空则说明软件包package1不依赖其它软件包，跳转至步骤S10或步骤S11，不为空则继续执行步骤S6；

步骤S6：判断软件包package1是否存在依赖冲突，若存在则结束整个流程并输出结果，若不存在，则继续执行步骤S7；

步骤S7：遍历软件包列表packlistⅠ，从中顺序获取一个软件包packageⅠ，检测软件包候选版本的情况，若没有候选版本，则结束整个流程并输出结果，若有候选版本，则获取候选版本号并继续执行步骤S8；

步骤S8：判断候选版本号是否满足安装要求，若不满足安装要求，则结束整个流程并输出结果，若满足安装要求，则跳转至步骤S7继续顺序获取下一个软件包packageⅡ，直至软件包列表中所有的软件包packageⅠ、软件包packageⅡ……均具备符合要求的候选版本；

步骤S9：递归跳转至步骤S2，按照步骤S2-步骤S8的方法，对软件包列表packlistⅠ中的软件包packageⅠ、软件包packageⅡ……的依赖完整性进行循环递归检查；

步骤S10：判断是否完成循环递归检查，若完成，则跳转至步骤S11；

步骤S11：跳转至步骤S2，从软件包列表packlist1中顺序获取软件包package2、软件包package3……，并依次完成其依赖完整性检测，直至遍历完软件包列表packlist1中的所有软件包，然后结束整个流程。

2.如权利要求1所述的快速检测apt仓库源依赖完整性的方法，其特征在于，所述步骤S1中，若用户输入了指定的软件包包名，仅检测传入的软件包的依赖完整性；若用户未输入软件包包名，则遍历软件源中所有的软件包，检查所有软件包的依赖完整性。

3.如权利要求1所述的快速检测apt仓库源依赖完整性的方法，其特征在于，所述步骤S6中，通过如下步骤判断某个软件包package是否存在依赖冲突：

步骤S61：获取该软件包package所依赖的软件包package-a、package-b……，得到该软件包的依赖链；

步骤S62：针对依赖链上的软件包package所依赖的每一个软件包package-a、package-b……，找出与其各自存在冲突关系的软件包，并判断与其各自存在冲突关系的软件包是否包括软件包package，若包括，则说明当前正在检测的软件包package存在依赖冲突，若不包括，则说明当前正在检测的软件包package不存在依赖冲突。

4.如权利要求3所述的快速检测apt仓库源依赖完整性的方法，其特征在于，所述步骤S61中，获取软件包package所依赖的软件包package-a、package-b……时，依赖关系包括Depends和Pre-Depends；

所述步骤S62中，针对依赖链上的软件包package所依赖的每一个软件包package-a、package-b……，找出与其各自存在冲突关系的软件包时，冲突关系包括break和conflicts。

5.如权利要求1所述的快速检测apt仓库源依赖完整性的方法，其特征在于，所述步骤S7中，通过如下方法获取软件包的候选版本号：找出软件包所隶属的所有软件源，将软件源按照优先级排序，以优先级最高的软件源中的该软件包的版本号作为该软件包的候选版本号；

若软件包所隶属的所有软件源优先级相同，则以该软件包在各软件源的最高版本号作为候选版本号；

若优先级最高的软件源中的该软件包对应有多个版本号，则以多个版本号中最高的版本号作为该软件包的候选版本号。

6.如权利要求1所述的快速检测apt仓库源依赖完整性的方法，其特征在于，所述步骤S5中，针对第一层软件包，若所获取的其直接依赖的软件包列表为空，则跳转至步骤S11，直接遍历下一个软件包；针对第一层软件包依赖链上的第二层之后的软件包，若所获取的其直接依赖的软件包列表为空，则跳转至步骤S10，判断该软件包所处的递归周期中所涉及到的其它软件包是否均已完成依赖完整性检测。

Images