CN102073582A - 基于冲突的软件包依赖关系检查方法 - Google Patents

Abstract

本发明提供了一种基于冲突的软件包依赖关系检查方法，该方法包括：从软件包依赖关系描述文件中读取依赖信息并生成软件包依赖关系树；提取软件包的依赖包集，并进行存在性检查；根据依赖包集获取冲突包集；依次处理冲突包集的冲突；若所有冲突都能够解决，则软件包依赖可满足，反之则不满足。本发明是面向Linux分发端的软件包依赖关系管理，从冲突的角度出发，通过排除与软件包关联的冲突，来对Linux分发端的软件包依赖完整性进行检查。

Description

基于冲突的软件包依赖关系检查方法

技术领域

本发明涉及软件包管理技术领域，特别是指适用于Linux分发端的，对Linux下的软件包依赖关系可满足性检查的方法。

背景技术

当前管理软件包之间复杂依赖关系的工具或方法从用途上来说主要分为两种：基于客户端的包依赖管理工具和基于分发端的包依赖管理工具。在客户端包依赖管理工具方面，通常Linux分发版本都提供客户端依赖管理工具以支持客户端的包管理，如Debian Linux的apt-get，RedHatLinux的yum，Suse Linux的red carpet等，而且有研究人员针对apt-get和yum存在的不完整性等问题，研究形成了优化的或性能更好的客户端包管理工具，如Smart和Optimal。分发端包依赖管理工具方面，目前没有相关的工具，大多都是复用客户端的软件包管理工具，由维护人员进行进一步的管理。但是随着分发端的规模不断扩大，现有的软件包管理工具并不能完成分发端的软件包依赖完整性检查，维护人员工作量日益庞大。

因此，随着Linux功能的不断扩充和增长，如何有效地维护数量庞大的软件包之间的依赖关系，是所有Linux操作系统厂商面临的共同挑战：新软件包是否与原有软件包集合中的各软件包存在冲突？新软件包依赖的所有软件包在原有软件包集合中是否存在？当原有软件包集合中的某个软件包获得更新时，原来的依赖关系是否依然存在，或是否导致冲突？当原有软件包集合中的某个软件包被删除或弃用时，原来的依赖关系是否仍然能够保持，或需要重新调整，或导致局部依赖链被破坏？根据行业用户的特殊需求，如何快速制定出一个专用的Linux操作系统发布版本，其中只包含所需的软件包？而当用户安装、卸载、更新软件包时，软件包集合依赖关系的更新维护对用户来说应该是透明的。

这些问题的解决可以归结为：在一个软件包集合中，任意一个软件包是否依赖可满足？

而对于软件包依赖关系检查技术来说，尚没有关于可以利用软件包之间的冲突关系来检查软件包依赖关系的方法。

本发明基于冲突的依赖关系检查方法是基于在实际检查环境中引发依赖不满足的原因和虚假冲突的大量存在而提出的，本发明考虑到DEB包格式中的复合依赖设定了优先级的概念，同样适用于DEB和RPM两种包格式分发端的依赖完整性检查，由于RPM包格式分发端中的虚假依赖比例很高，应用本发明可以达到很高的效率，故本发明多用于RPM包格式分发端的依赖完整性检查。

发明内容

有鉴于此，本发明的主要目的在于解决上述问题，减轻维护人员工作强度，提高分发端软件包管理的自动化程度，提供一种基于冲突的软件包依赖关系检查方法，所要解决的技术问题如何对Linux分发端软件包依赖完整性进行检查，以提高软件包依赖关系管理的效率，降低软件包之间的依赖关系管理的复杂度。

对于上述技术问题，本发明是这样加以解决的。基于冲突的软件包依赖关系检查方法，包括以下步骤：步骤10：从软件包依赖关系描述文件graphml.xml中读取依赖信息并生成软件包依赖关系树；步骤20：根据依赖信息树，提取软件包的依赖包集，并对依赖包集中的每一项进行存在性检查；步骤30：根据依赖包集获取冲突包集；步骤40：依次处理冲突包集的冲突；步骤50：若所有冲突都能够解决，则软件包依赖可满足，反之则不满足。

本发明的目的及解决其技术问题还可以采用以下技术措施进一步实现。

前述的基于冲突的软件包依赖关系检查方法，其中所述的步骤10中的软件包依赖关系描述文件graphml.xml是依据专利发明申请书《一种软件包依赖关系建模方法》得到的软件包依赖关系描述文件，该描述文件采用扩展的GraphML文件格式描述。

《一种软件包依赖关系建模方法》，其步骤包括：

第一步，解析软件包中的依赖关系表示为统一软件包元数据格式Package格式，这一步可以细分为以下三个小步骤根据各种不同的Linux软件包格式，从依赖关系建模的角度，提出一种统一的软件包元数据格式Package格式及其XML表示方法；根据输入的软件包格式，读取此种软件包格式的包基的软件包文件或包基的描述文件，解析并提取软件包元数据的依赖信息；将获得的依赖信息转换为统一软件包元数据格式Package格式，并用XML表示为统一软件包元数据描述的包基描述文件。

第二步，将表示为统一软件包元数据格式Package格式的依赖关系用扩展的GraphML语言描述并将其可视化，这一步可以细分为以下三个小步骤：基于包基建模需求，对GraphML进行扩展，得到扩展的GraphML格式；将Package结构转换为扩展的GraphML文件格式描述，生成graphmlxml文件；读取graphml.xml并将其可视化。

其中，该统一的软件包元数据格式从依赖关系建模的角度提出，只包含了依赖关系建模所需的必须信息，其定义如表1所示；该扩展的GraphML是基于GraphML，通过为其元素增加属性和增加<data>元素内容的方式对其进行了扩展，图2为扩展的GraphML格式。

表1统一软件包元数据格式的定义

前述的基于依赖的软件包依赖关系检查方法，其中所述的步骤10进一步包括：步骤101：从软件包依赖关系描述文件中读取依赖信息；步骤102：从软件包集合中选择某个软件包；步骤103：根据选择的软件包和所读取的依赖信息生成依赖关系树。

对于上述技术问题，本发明考虑到DEB包格式中的复合依赖设定了优先级的概念，包括依赖等级和冲突等级，同样适用于DEB和RPM两种包格式分发端的依赖完整性检查。

优选的是，本发明基于冲突的依赖关系检查方法的关键是处理冲突。处理冲突就是判断该项冲突是否为可以解决的。如果一个软件包的依赖包都是存在的，那么造成软件包依赖不满足的主要原因就是依赖包集中存在彼此相互冲突的软件包或者存在与当前软件包冲突的软件包。本发明首先判断依赖包集中是否存在依赖包，然后处理冲突包集中的冲突，如果依赖包不存在或者冲突包集中的冲突不能解决，则该软件包依赖不可满足。

本发明与现有技术相比具有明显的优点和有益效果。借由上述技术方案，本发明基于冲突的软件包依赖关系检查方法具有下列优点及有益效果：

1.冲突依赖较为少见，是一种负依赖关系，即软件包P1和P2无法共同存在。在RPM软件包格式的操作系统只允许存在一个版本的软件包，许多冲突依赖的冲突软件包在系统中是不存在的。所以从冲突的角度出发，对软件包依赖关系进行检查对于RPM包格式的分发端效率会更高。

2.本发明能够很好的对RPM包格式的分发池进行完整性检查，同时也能够对RPM包格式的分发池进行完整性检查。

综上所述，本发明具有上述优点及有益效果，在方法和功能上皆有较大的改进，在技术上有显著的进步，并具有产业的广泛利用价值。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图，详细说明如下。

附图说明

图1为基于冲突的软件包依赖关系检查方法流程图。

图2为扩展的GraphML格式。

图3为由九个软件包组成的一个包基的包间依赖关系“与-或图”。

具体实施方式

为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效，以下结合附图及较佳实施例，对依据发明提出的基于冲突的软件包依赖关系检查方法其具体实施方式、方法、步骤、结构、特征及其功效，详细说明如后。

有关本发明的前述及其他技术内容、特点及功效，在以下配合参考图式的详细说明中将可清楚呈现。通过具体实施方式的说明，当可对本发明为达成预定目的的所采取的技术手段及功效得以更加深入且具体的了解，然而所附图式仅是提供参考与说明之用，并非用来对本发明加以限制。

为了能够更好的理解本发明的内容，下面给出一些相关的概念：

软件包直接依赖关系约束的形式化表示

设D_r和D_c分别为p的依赖和冲突的软件包集合，直接依赖集合

，其中，集合D(p)的元素y为软件包或软件包析取组合(p_i∨…∨p_j)。如果p与其它软件包不存在依赖或冲突，则

直接依赖集合D的λ赋值D^λ(P)，表示对集合中析取式的一次赋值。即对D中每一析取组合，选取其中的某一软件包表示该组合，赋值后，D^λ(P)为p的一个直接依赖软件包集合。

软件包的依赖可满足性

对于一个软件包集合R，R中软件包p的依赖可满足性指，在软件包集合R中，存在一个赋值λ，D^λ(X)为依赖函数，定义D^λ(X)为X的直接依赖软件包的集合。D^nλ(p)表示D^λ(D^λ(D^λ(...(D^λ(p)...)))，对子集

中任一软件包x，使得，

并且

软件包依赖子集

根据依赖可满足性定义，赋值λ所确定的P，称为软件包p的一个依赖子集，依赖子集P是递归生成的，是一种特殊的传递闭包。λ是相对于整个软件包集合R的依赖可满足性赋值。

软件包的可安装性

对于软件包集合R，给定一个软件包p，如果p相对于软件包集合R符合依赖可满足性，则称p在软件包集合R上可安装。

本发明中Linux操作系统中包含的软件包是Linux分发池的子集，一个Linux分发池中包含一个或多个Linux操作系统。

Linux分发池/操作系统包集R＝(P，D，C)。其中P为软件包集合，D:P→ψ(ψ(P))为依赖函数，ψ(X)表示X的子集的集合。

为冲突关系。关系C是对称的。例如对于所有的(p₁，p₂)∈C当且仅当(p₂，p₁)∈C。对于一个Linux分发版本来说，标识名相同版本号不同的软件包默认为相互冲突。例如，p₁＝(u，v₁)，p₂＝(u，v₂)，并且v₁≠v₂，则(p₁，p₂)∈C。

Linux分发池/操作系统包集R应该具有的特性：

完整性：R中每一个软件包都是依赖可满足的，即都是可安装的。

Linux软件包依赖树

Linux软件包依赖树又称依赖树。Linux操作系统以及分发端的软件包间依赖关系为一个有向图，结点间关系为依赖关系和冲突关系，依赖与冲突关系中的“与依赖”和“或依赖”可采用扩展的“与-或”图。为了更好的将依赖关系向SAT问题映射，本文定义依赖结点这一概念，依赖结点分为直接依赖结点(类似图3中软件包b)和复合依赖结点(类似图3中的结点c或者d)。依赖结点之间的关系为“与依赖”。

依赖包集

软件包A的依赖包集是指所有软件包A所依赖的软件包集合。例如软件包的依赖包集为P，那么如果软件包A依赖软件包B，则B∈P，如果软件包C∈P，而软件包C依赖软件包D，那么D∈P。

冲突包集

软件包A的冲突包集P1是指所有与依赖包集中软件包冲突的软件包集合.例如软件包A∈P0，P0为软件包A的依赖包集，如果软件包A与软件包B冲突，那么B∈P1。

虚假冲突

软件包A的依赖关系中存在一条冲突依赖表示其与软件包B冲突，但是在软件包A所在的分发池中并不存在软件包B，则称该冲突依赖为虚假冲突

冲突和依赖的等级

为了更好地对软件包依赖完整性进行检查，对依赖集中的软件包进行依赖和冲突的等级划分，依赖等级越高，优先级越高，冲突等级越高，优先级越高。

依赖等级：在软件包Q的依赖集中，如果软件包P依赖软件包A，那么软件包A的依赖等级为0(最高级)，如果软件包A依赖软件包B∨C，而软件包B依赖软件包D，那么软件包D的依赖等级低于软件包A一级，而依赖B∨C的依赖等级与A相同。如果软件包A依赖软件包B，那么软件包B的依赖等级与A相同。

冲突等级：如果冲突包集中的软件包A由依赖包集中的软件包B产生，那么软件包A的冲突等级与软件包B的依赖等级相同。如果由依赖包集中的B∨C中的B产生，那么软件包A的冲突等级比B∨C的依赖等级低一级。

请参阅图1所示，为本发明提出的基于冲突的软件包依赖关系检查方法的流程图，包括以下步骤：

步骤10：从软件包依赖关系描述文件graphml.xml中读取依赖信息并生成软件包依赖关系树。

一般而言，软件包之间的依赖关系可分为两类：需求依赖和冲突依赖。需求依赖是一种常见的依赖关系，即为安装软件包P1，必须首先安装软件包P2，P1对P2存在着需求依赖；冲突依赖较为少见，是一种负依赖关系，即软件包P1和P2无法共同存在。

从软件包依赖关系描述文件graphml.xml中读取依赖信息并生成软件包依赖关系树做详细说明，它包括以下三个步骤：

步骤101：从软件包依赖关系描述文件graphml.xml中读取依赖信息。

本发明中提取的依赖信息是从软件包依赖关系描述文件graphml.xml中读取的，其中，graphml.xml是依据专利发明申请书《一种软件包依赖关系建模方法》中得出的软件包依赖关系描述文件，是采用扩展的GraphML文件描述的，基于扩展的GraphML表示软件包依赖关系图，如图2所示。图示说明，依赖关系图由节点node、边edge和超边hyperedge组成。图中利用节点node表示组成包基的软件包，边edge表示两个软件包间的依赖关系，超边hyperedge表示软件包间的“或依赖”关系。每个软件包都会有一个版本号(version)作为一个重要的标识，RPM和DEB软件包的版本号格式相同的。版本号是标识软件包之间依赖关系的一个重要依据。RPM和DEB软件包元数据中描述的依赖类型大部分是相同的，只有一些特殊用途的依赖关系是不同的(例如：obsoletes，replaces)，而这些依赖关系对软件包依赖完整性的影响并不大。因此本发明只提取三种主要的依赖关系，作为判断软件包依赖完整性的依据。具体如下：

run(Depends关系)：用来表示主要依赖的软件包，如果当前软件包要安装或者运行，系统中必须存在的软件包。

conflict(Conflicts关系)：用来表示与当前软件包冲突的软件包，如果当前软件包要安装或者运行，系统中不能存在的软件包。一个软件包要完成安装或者运行必须保证系统中不存在与之冲突的软件包。

install(Pre-Depends关系)：与depends关系类似，表示当前软件包要安装或者运行，系统中必须存在的软件包，不同之处在于depends依赖的软件包在当前软件包安装的时候可以不存在于系统中，但是安装完成后会与当前软件包同时展开到系统中；Pre-Depends依赖的软件包在当前软件包安装时就必须已经存在于系统中。

本发明以一个简化的GraphML文件作为较佳实施例，假设graphml.xml内容如下：

<graphml>

  <graph edgedefault＝′directed′version_type＝′rpm′>

    <node package＝′a′id＝′a′/>

    <node package＝′b′id＝′b′/>

<node package＝′c′id＝c′/>

<node package＝′c′id＝d′/>

<node package＝′c′id＝e′/>

<node package＝′c′id＝f′/>

<node package＝′c′id＝g′/>

<node package＝′c′id＝h′/>

<node package＝′c′id＝i′/>

    <edge type＝′run′source＝′a′target＝′b′/>

    <edge type＝′run′source＝′b′target＝′f′/>

    <edge type＝′run′source＝′b′target＝′g′/>

    <edge type＝′run′source＝′c′target＝′g′>/

    <edge type＝′run′source＝′e′target＝′i′/>

    <edge type＝′conflict′source＝′c′target＝′e′/>

    <edge type＝′conflict′source＝′g′target＝′h′/>

    <hyperedge type＝′run′>

      <ehdpoint type＝″out″node＝″a″/>

      <endpoint type＝″in″node＝″c″/>

      <endpoint type＝″in″node＝″d″/>

</hyperedge>

<hyperedge type＝′run′>

   <ehdpoint type＝″out″node＝″a″/>

       <endpomt type＝″in″node＝″d″/>

       <endpoint type＝″in″node＝″e″/>

   </hyperedge>

   <hyperedge type＝′run′>

      <endpoint type＝″out″node＝″d″/>

      <endpoint type＝″in″node＝″g″/>

      <endpoint type＝″in″node＝″h″/>

      <endpoint type＝″in″node＝″i″/>

   </hyperedge>

  </graph>

</graphml>

由上可见，为了简化问题，该graphml.xml文件中只包含9个软件包节点分别为a、b、c、d、e、f、g、h、i，每个节点元素仅给出了packagename属性，version和privade均已省略；软件包a与依赖b，a或依赖c和d，a或依赖d和e，b与依赖f和g，c与依赖g，d或依赖g、h和i，e与依赖i，c与e冲突，g与h冲突。

步骤102：从软件包集合中任选一个软件包。

在软件包集中任选一个软件包，假设选择软件包a，要判断软件包a是否可安装的为待描述的基于冲突的软件包依赖关系检查方法示例。

步骤103：根据选择的软件包和所读取的依赖信息生成依赖关系树。

软件包依赖树为一个有向图，结点间关系为依赖关系和冲突关系，依赖与冲突关系中的“与依赖”和“或依赖”可采用扩展的“与-或，，图表示，扩展的虚线表示冲突关系。根据较佳实施例中要判断的软件包a，提取与其直接或者间接相关的软件包共8个，分别为b、c、d、e、f、g、h、i。根据前述步骤102提取的依赖信息：软件包a与依赖b，a或依赖c和d，a或依赖d和e，b与依赖f和g，c与依赖g，d或依赖g、h和i，e与依赖i，c与e冲突，g与h冲突，生成的软件包依赖关系树如图3所示。软件包a为依赖关系树的根，c与e、g与h之间存在冲突，用扩展的虚线表示冲突关系。由图3可知，若要安装a，先要安装b，c或d，d或e。c和e不能同时安装。a可安装即至少存在一个依赖满足解。对于一个分发池或者Linux版本的依赖完整性即其中所有软件包都有依赖满足解，即都是可安装的。

步骤20：根据依赖信息树，提取软件包的依赖包集，并对依赖包集中的每一项进行存在性检查。

较佳实施例中，根据软件包a的依赖信息树，如图3所示，对软件包a进行可安装判断：1)首先提取软件包a的依赖包集，从图3可知：

若要安装a，先要安装b，c或d，d或e；

若要安装b，先要安装f，g；

若要安装c，先要安装g；

若要安装d，先要安装g或h或i；

若要安装e，先要安装i；

软件包a的依赖等级为最高级0；

软件包a依赖b，故b的依赖等级与a相同为0；

软件包a依赖c∨d，故c∨d的依赖等级与a相同为0；

软件包a依赖d∨e，故d∨e的依赖等级与a相同为0；

软件包b依赖f和g，故f和g的依赖等级与b相同都为0；

软件包d依赖g∨h∨i，故g∨h∨i的依赖等级低于软件包a一级，为1；

软件包e依赖i，故i的依赖等级低于软件包a一级，为1。

由此可知软件包a的依赖包集为D(a)＝{{b-0}，{c，d-0}，{d，e-0}，{f-0}，{g-0}，{g，h，i-1}，{i-1}}，其中‘-’后面的数字代表依赖等级，数字越小依赖等级越高，优先级也越高。

2)然后对依赖包集中的每一项进行存在性检查。检查依赖包集D(a)中每一项是否都存在，或依赖项中只要有一软件包存在即可。如果有一项不存在，则软件包a不可安装，原因是依赖包不满足；如果依赖包集中的每一项都存在，则存在性检查完毕。依赖包集D(a)＝{{b-0}，{c，d-0}，{d，e-0}，{f-0}，{g-0}，{g，h，i-1}，{i-1}}共有7项，对每一项进行存在性检查其如下：

软件包b存在，故项{b-0}满足；

软件包c或d其中之一存在，故项{c，d-0}满足；

软件包d或e其中之一存在，故项{d，e-0}满足；

软件包f存在，故项{f-0}满足；

软件包g存在，故项{g-0}满足；

软件包g或者h或者i存在，故项{g，h，i-0}满足；

软件包i存在，故项{i-0}满足，

由此可知，依赖包集D(a)中每一项都存在，故存在性满足。

步骤30：根据依赖包集获取冲突包集。

根据较佳实施例，软件包a的依赖包集D(a)中的每一项中软件包满足存在性的，则提取与依赖包集D(a)对应的冲突包集C(a)。从图3中可知：

软件包c和e不能同时安装；

软件包g和h不能同时安装；

故冲突包集中的软件包为c、e、g、h。

软件包c由依赖包集中的d∨e中的e产生，那么软件包c的冲突等级比d∨e的依赖等级低一级，为1；

软件包e由依赖包集中的c∨d中的c产生，那么软件包e的冲突等级比c∨d的依赖等级低一级，为1；

软件包g由依赖包集中的g∨h∨i中的h产生，那么软件包g的冲突等级比g∨h∨i的依赖等级低一级，为2；

软件包h由依赖包集中的软件包g产生，那么软件包h的冲突等级与软件包g的依赖等级相同，为0。

由此可知与依赖包集D(a)对应的冲突包集C(a)为：C(a)＝{{h-0}，{e-1}，{c-1}{g-2}}，其中‘-’后面的数字代表冲突等级，数字越小冲突等级越高，优先级也越高。

步骤40：依次处理冲突包集的冲突。

根据较佳实施例步骤30后，对冲突包集C(a)中各项冲突优先级从高到低进行处理。

对于冲突等级最高的冲突h-0，冲突目标软件包h在依赖包集中存在，并且是可以处理的，原因是软件包d或依赖g、h和i，删除h并不会造成软件包d不可安装，故h是可以处理的。删除软件包h后，冲突包集中的g没有与之冲突的软件包了，故软件包g也将从冲突包集中删除，处理后依赖包集为D(a)＝{{b-0}，{c，d-0}，{d，e-0}，{f-0}，{g-0}，{g，i-1}，{i-1}}，冲突包集为C(a)＝{{e-1}，{c-1}}}。

继续对冲突包集C(a)中各项冲突优先级从高到低进行处理直至为空，因为冲突e-1与c-1优先级相同，可以任选其一进行处理。假设先处理冲突e-1，冲突目标软件包e在依赖包集中存在，并且是可以处理的，原因是软件包a或依赖d和e，删除e并不会造成软件包a不可安装，故e是可以处理的。将软件包e删除后，冲突包集中的c没有与之冲突的软件包了，故软件包c也将从冲突包集中删除，处理后的依赖包集为：D(a)＝{{b-0}，{c，d-0}，{d-0}，{f-0}，{g-0}，{g，i-1}}，冲突包集为C(a)＝{}。如果先处理冲突c-1，则处理后的依赖包集为D(a)＝{{b-0}，{d-0}，{d，e-0}，{f-0}，{g-0}，{g，i-1}，{i-1}}，冲突包集为C(a)＝{}。

步骤50：若所有冲突都能够解决，则软件包依赖可满足，反之则不满足。

根据步骤40，D(a)＝{{b-0}，{c，d-0}，{d-0}，{f-0}，{g-0}，{g，i-1}}，C(a)＝{}和D(a)＝{{b-0}，{d-0}，{d，e-0}，{f-0}，{g-0}，{g，i-1}，{i-1}}，C(a)＝{}这两种结果冲突包集C(a)都为空，那么可以判断软件包a是可以安装的。

如果，假设软件包g与d冲突而不是与h冲突那么冲突包集和依赖包集为D(a)＝{{b-0}，{c，d-0}，{d，e-0}，{f-0}，{g-0}，{g，h，i-1}，{i-1}}C(a)＝{{d-0}，{e-1}，{c-1}{g-1}}

然后对冲突包集C(a)中各项冲突优先级从高到低进行处理，对于冲突d-0，冲突目标软件包d在依赖包集中存在，并且是可以处理的，处理后的依赖包集和冲突包集为：D(a)＝{{b-0}，{c-0}，{e-0}，{f-0}，{g-0}，{i-1}}知C(a)＝{{e-1}，{c-1}}}

继续对冲突包集C(a)中各项冲突优先级从高到低进行处理直至为空，处理e-1，冲突目标软件包h在依赖包集中存在，并且是可以处理的，处理后的依赖包集和冲突包集为：D(a)＝{{b-0}，{c-0}，{-0}，{f-0}，{g-0}}，C(a)＝{}和D(a)＝{{b-0}，{-0}，{e-0}，{f-0}，{g-0}，{i-1}}，C(a)＝{}两种结果依赖包集中都存在某项依赖为空，那么可以判断软件包a是不可安装的，原因是软件包a依赖的软件包中存在逻辑冲突。

另外ConflictIntegritySolvers算法，描述了基于冲突的软件包依赖关系检查方法。具体算法如下：

基于冲突的软件包依赖关系检查方法：ConflictIntegritySolver(R)

输入：包基R；

输出：包基的依赖完整性检查结果，包括每个软件包的可安装解或无解判定结果；

for(each软件包p∈R){

提取包基R中软件包p的依赖关系图PDG；

从PDG中提取依赖包集A；

if(A are all existing)提取冲突包集B；else输出“unsat somepackage is not existing”

对冲突包集B中的冲突进行处理，返回result；

if(result为0)输出“unsat the conflict package is”else输出sat；

}

以上所述，仅是本发明的较佳实施例而已，并非对本发明做任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明，任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内，当可利用上述揭示的方法及技术内容作出些许的更改或修饰为等同变化的等效实施例，但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。

Claims (4)

1.一种基于冲突的软件包依赖关系检查方法，用于Linux分发端的软件包依赖关系管理，其特征在于，其包含以下步骤：

步骤10：从软件包依赖关系描述文件graphml.xml中读取依赖信息并生成软件包依赖关系树；

步骤20：根据依赖信息树，提取软件包的依赖包集，并对依赖包集中的每一项进行存在性检查；

步骤30：根据依赖包集获取冲突包集；

步骤40：依次处理冲突包集的冲突；

步骤50：若所有冲突都能够解决，则软件包依赖可满足，反之则不满足。

2.依据权利要求1所述的方法，其特征在于，其中所述的步骤10还包括：

步骤101：从软件包依赖关系描述文件graphml.xml中读取依赖信息；

步骤102：从软件包集合中任选一个软件包；

步骤103：根据选择的软件包和所读取的依赖信息生成依赖关系树。

3.依权利要求1所述的基于冲突的依赖关系检查方法，其特征在于，对依赖集中的软件包进行依赖和冲突的等级划分，依赖等级越高，优先级越高，冲突等级越高，优先级越高。

4.依权利要求1所述的基于冲突的依赖关系检查方法，其特征在于，步骤40所述的对冲突依赖的处理，判断该项冲突是否可以解决，具体流程为首先遍历依赖包集判断依赖包集中每一项中软件包是否都存在，如果存在性不满足，则表示该软件包不可安装，如果存在，判断冲突包的优先级，依据优先级的高低标记删除冲突包，如果存在冲突包不能标记删除，则表示冲突包不能解决，该软件包依赖不满足。

Images