專利名稱:軟件包依賴關系建模方法
技術領域:
本發(fā)明涉及軟件包管理技術領域特別是指一種適用于Linux操作系統(tǒng)的,對 Linux下的軟件包中存在的依賴關系進行提取并統(tǒng)一建模的方法。
背景技術:
隨著Linux操作系統(tǒng)的廣泛發(fā)展,Linux操作系統(tǒng)的管理越來越受到人們的重視 一個Linux操作系統(tǒng)分發(fā)版是由大量的可安裝的軟件包組成的。伴隨著互聯(lián)網(wǎng)的發(fā)展, Linux操作系統(tǒng)的規(guī)模也越來越大,所包含的軟件包的數(shù)量也越來越多。軟件包之間存在著 大量復雜的依賴關系。同時,Linux系統(tǒng)擁有多種分發(fā)版本,有多種不同的軟件包格式。如Redhat Linux 軟件包為RPM格式,Debian Linux為DEB格式,軟件包也可以為tgz或pkg格式。不同的 軟件包格式有著較大差異。這同樣增加了 Linux軟件包管理的難度。具體來說,Linux下的軟件包管理可分為客戶端軟件包管理和分發(fā)池軟件包管理 兩中不同的類型,分別負責軟件包的本地安裝維護、依賴關系處理(根據(jù)依賴關系計算結(jié) 果自動從分發(fā)系統(tǒng)中獲取所需的軟件包)和分發(fā)端的軟件包維護。由于Linux操作系統(tǒng)的規(guī)模和復雜性通常一個分發(fā)版本由幾千個可安裝單元包 組成,這使得可安裝軟件包分發(fā)池的規(guī)模龐大,軟件包之間的依賴關系更為復雜。通過可安 裝軟件包依賴關系管理保證每個可安裝軟件包的可安裝性、Linux操作系統(tǒng)分發(fā)版本和分 發(fā)池的依賴完整性。由人工來完成可安裝軟件包依賴關系管理的話,分發(fā)池的規(guī)模,以及 頻繁的版本變更和更新,使得該任務在集成和更新支持過程中為一個成本很高的活動。所 以,分發(fā)池的軟件包管理工作就變得非常重要。在國外,國外著名的Linux分發(fā)廠商如Red Hat、Wxmtu等,都擁有自己的分發(fā)池管理工具,但這些工具都屬于企業(yè)的保密資源。在國 內(nèi),對于分發(fā)池的管理還都是由工作人員人工來完成。目前,對于軟件包依賴建模的工具數(shù)量并不是很多,而且多數(shù)都屬于企業(yè)專用的 工具。在客戶端卻存在幾個可以展示包依賴關系的工具。1. apt-rdepends :apt_rd印ends可以提取軟件包的依賴信息,并將所提取的依賴 信息格式化為Dot語言文件。它與Graphviz的組件Dot—起工作就可以顯示出某個軟件 包的依賴關系。這個工具功能上有較多的限制,它只能顯示的軟件包的依賴信息,不能顯示 沖突信息。在元數(shù)據(jù)提取上,它并沒有解析所有的包的元數(shù)據(jù),而只是對Depends關系進行 了解析。2. Linux包依賴的可視化工具在網(wǎng)上有一個人做了一個關于Linux包依賴的可 視化工具,它是一個web系統(tǒng),服務端用Python語言框架Django寫成,將包的依賴信息提 取后格式化為json的數(shù)據(jù)格式??蛻舳耸褂肕ootools包解析json數(shù)據(jù),其可視化結(jié)果是 通過利用JavaScriptlnfoVis ToolKit包來實現(xiàn)的。3. Ignominy Ignominy是在項目CMS IGUANA中開發(fā)出來的一個工具,它是用來對 軟件系統(tǒng)進行分析的。它的主要部分是一個構件依賴關系的查看器,這個查看器會將依賴關系詳細的解析成為可讀的格式。它同時還包括了可視化收集到的數(shù)據(jù)為圖像的工具。這 個工具主要用途是能夠查看自己開發(fā)的軟件可能出現(xiàn)的結(jié)構錯誤,來改進軟件的質(zhì)量。同 時它還可以對現(xiàn)在正在使用的外部組件進行評估和研究學習。但是,上述可以展示包依賴關系建模工具都是基于客戶端軟件包管理,并非分發(fā) 池軟件包管理,而基于客戶端軟件包管理主要負責軟件包的本地安裝維護、依賴關系處理, 并不適用于分發(fā)端的軟件包依賴關系管理。對于分發(fā)端軟件包依賴關系建模技術來說,尚 沒有公開的Linux下的軟件包依賴關系建模方法。
發(fā)明內(nèi)容
有鑒于此,本發(fā)明的主要目的在于針對Linux軟件包格式眾多、依賴關系復雜的 情況,提供一種基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方法,所要 解決的技術問題是如何對分發(fā)端的軟件包依賴關系進行建模,以提高軟件包依賴關系管理 的效率,降低軟件包之間的依賴關系管理的復雜度。本發(fā)明的目的及解決其技術問題是采用以下技術方案來實現(xiàn)的。依據(jù)本發(fā)明提出 的一種基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方法,其包括以下步 驟步驟10 解析軟件包中的依賴關系表示為統(tǒng)一軟件包元數(shù)據(jù)格式Package格式;步驟 20 將表示為統(tǒng)一軟件包元數(shù)據(jù)格式lockage格式的依賴關系用擴展的GraphML語言描述, 并將其可視化;其中,該統(tǒng)一的軟件包元數(shù)據(jù)格式從依賴關系建模的角度提出,只包含了依 賴關系建模所需的必須信息;該擴展的GraphML是基于GraphML,通過為其元素增加屬性和 增加<data>元素內(nèi)容的方式對其進行了擴展。本發(fā)明的目的及解決其技術問題還可以采用以下技術措施進一步實現(xiàn)。前述的基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方法,其中 所述的步驟10還包括步驟101 根據(jù)各種不同的Linux軟件包格式,從依賴關系建模的角 度,提出一種統(tǒng)一的軟件包元數(shù)據(jù)格式Package格式及其XML表示方法;步驟102 根據(jù)輸 入的軟件包格式,讀取此種軟件包格式的包基的軟件包文件或包基的描述文件,解析并提 取軟件包元數(shù)據(jù)的依賴信息;步驟103 將獲得的依賴信息轉(zhuǎn)換為統(tǒng)一軟件包元數(shù)據(jù)格式 Package格式,并用XML表示為統(tǒng)一軟件包元數(shù)據(jù)描述的包基描述文件。前述的基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方法,其中 所述的步驟101進一步包括步驟1011 根據(jù)各種不同的Linux軟件包格式,從依賴關系建 模角度給出統(tǒng)一軟件包元數(shù)據(jù)格式Package格式所包含的元素;步驟1012 給出Package 格式中所包含的元素的描述性定義;步驟1013 根據(jù)Package格式,給出Package格式的 XML表示方法;所述的步驟102進一步包括步驟1021 根據(jù)輸入的軟件包格式,判斷軟件 包基的格式;步驟1022 根據(jù)包基的格式,讀取此種格式的包基的軟件包文件或包基的描 述文件;步驟1023 根據(jù)讀取的軟件包文件或包基的描述文件,解析并提取軟件包元數(shù)據(jù) 的依賴信息;步驟103進一步包括步驟1031 將提取的軟件包元數(shù)據(jù)的依賴信息轉(zhuǎn)換為 面向依賴建模的Package結(jié)構;步驟1032 將Package結(jié)構轉(zhuǎn)換為用XML表示的統(tǒng)一軟件 包元數(shù)據(jù)描述的包基描述文件。前述的基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方法,其 中所述的步驟20還包括步驟201 基于包基建模需求,對GraphML進行擴展,得到擴展的GraphML格式;步驟202 將Package結(jié)構轉(zhuǎn)換為擴展的GraphML文件格式描述,生成 graphmlxml文件;步驟203 讀取graphml. xml并將其可視化。本發(fā)明與現(xiàn)有技術相比具有明顯的優(yōu)點和有益效果。借由上述技術方案,本發(fā)明 基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方法有下列優(yōu)點及有益效 果1.本發(fā)明支持多種不同軟件包格式元數(shù)據(jù)的提??;2.本發(fā)明采用統(tǒng)一軟件包元數(shù)據(jù)表示依賴關系,使用擴展的GraphML對依賴關系 進行統(tǒng)一建模,可以降低分發(fā)端軟件包管理的難度和軟件包維護成本,以及提高集成和更 新支持效率;3.本發(fā)明面向圖形方式描述軟件包依賴關系,可自動生成軟件包基描述文件和可 視化圖形;4.本發(fā)明中的軟件包元數(shù)據(jù)格式可以在提取軟件包間依賴關系時,每增加一種包 格式,無需要對依賴關系建模部分作出修改;5. GraphML與其它具有各自特有語法的圖形文件格式相比,其優(yōu)點為采用基于 XML的語法,這使得它成為了圖形產(chǎn)生、圖形文檔化處理的理想格式,而且允許用戶通過為 其元素增加屬性或為<data>元素增加結(jié)構化內(nèi)容的方式進行擴展。另外,GraphML支持超 邊,可以用來仿真“與-或圖”中的一個軟件包與多個軟件包間的“或依賴”關系。本發(fā)明 中的擴展的GraphML不僅具有GraphML的特性而且還滿足包基建模的需求6.本發(fā)明通過可安裝軟件包依賴關系管理保證每個可安裝軟件包的可安裝性、 Linux操作系統(tǒng)分發(fā)版本和分發(fā)池的依賴完整性。綜上所述,本發(fā)明具有上述優(yōu)點及有益效果,在方法和功能上皆有較大的改進,在 技術上有顯著的進步,并具有產(chǎn)業(yè)的廣泛利用價值。上述說明僅是本發(fā)明技術方案的概述,為了能夠更清楚了解本發(fā)明的技術手段, 而可依照說明書的內(nèi)容予以實施,并且為了讓本發(fā)明的上述和其他目的、特征和優(yōu)點能夠 更明顯易懂,以下特舉較佳實施例,并配合附圖,詳細說明如下。
圖1為Linux軟件包間依賴關系提取過程。圖2為統(tǒng)一軟件包元數(shù)據(jù)的XML表示。圖3為基于統(tǒng)一軟件包元數(shù)據(jù)包間依賴關系提取和建模過程。圖4為擴展的GraphML格式。圖5為libc6節(jié)點例子。圖6為一個edge節(jié)點例子。圖7為一個hyperedge節(jié)點例子。
具體實施例方式為更進一步闡述本發(fā)明為達成預定發(fā)明目的所采取的技術手段及功效,以下結(jié)合 附圖,對依據(jù)發(fā)明提出的基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方 法其具體實施方式
、方法、步驟、結(jié)構、特征及其功效,詳細說明如后。
有關本發(fā)明的前述及其他技術內(nèi)容、特點及功效,在以下配合參考圖式的詳細說 明中將可清楚呈現(xiàn)。通過具體實施方式
的說明,當可對本發(fā)明為達成預定目的的所采取的 技術手段及功效得以更加深入且具體的了解,然而所附圖式僅是提供參考與說明之用,并 非用來對本發(fā)明加以限制。為了能夠更好的理解本發(fā)明的內(nèi)容,下面給出一些相關的概念(1)可安裝單元包可安裝單元包是一種包含元數(shù)據(jù)、程序文件、配置信息和安裝腳本等內(nèi)容的文件 集合,是組成軟件的一個可安裝基本單位。在Linux操作系統(tǒng)中稱為軟件包,本文重點研究 了 Linux操作系統(tǒng)上的可安裝單元包的依賴關系管理,因此以下將可安裝單元包簡稱為軟 件包。(2)軟件包間的依賴關系一般而言,軟件包之間的依賴關系可分為兩類依賴和沖突。為了安裝軟件包pl, 必須首先安裝軟件包p2,pl對p2存在依賴關系;軟件包pl和p2無法共同存在,稱pl和 P2之間為沖突關系??梢詮能浖脑獢?shù)據(jù)文件獲取包的依賴和沖突約束信息。(3)軟件包的依賴可滿足性對于一個軟件包集合R,R中軟件包ρ的依賴可滿足性指,在軟件包集合R中,存 在一個賦值λ,Da(X)為依賴函數(shù),定義Da (X)為X的直接依賴軟件包的集合。DnA(p)
表示 Da (Da (Da (... (Da (ρ)...))),對子集 i^yzrI 內(nèi)中任一軟件包 X,使得 P^jdw,(4)軟件包可安裝對于軟件包集合R,給定一個軟件包P,如果P相對于軟件包集合R符合依賴可滿 足性,則稱P在軟件包集合R上可安裝。(5)或依賴、與依賴關系大部分的依賴關系為“與依賴”,如果軟件包A “與依賴”軟件包B和C,則表示軟 件包A在缺少B或C的情況下,都不能使用。有些軟件包格式可以支持“或依賴”關系,如果軟件包A “或依賴”軟件包B和軟 件包C,則表示軟件包A在B或C任一包存在情況下,就可以使用。在DEB軟件包格式中, Depends、Recommands、Suggests 禾口 Pre-Depends 關系都支持“或依賴,,。(6)依賴關系的表示一個依賴關系還經(jīng)常會限制它所依賴的版本。如果軟件包A依賴于libc6( > = 2. 4),就表明軟件包依賴于libc6,而且版本必須是大于或等于2. 4。一共有五種不同的關于包的版本的比較關系=完全相等;<=小于或等于;>=大于或等于;<小于;>大于。(7)虛包虛包是指一組具有近似功能的軟件的統(tǒng)稱,例如tin和trn都是新聞閱讀程序,為 系統(tǒng)中其它需要更新閱讀的程序提供服務。因此可以說它們都提供了“news-reader(新聞 閱讀)”的虛包。同樣,smail和sendmail的都提供了郵件傳輸代理的功能。因此說它們提供了“郵件傳輸代理(mail transport agent) ”的虛包,兩者安裝都可以滿足其它程序?qū)τ凇癿ail transport agent”的虛包要求。虛包沒有版本號。(8)依賴關系的分類Linux軟件包元數(shù)據(jù)中包含的8種不同的依賴關系如下Depends關系如果軟件包B與軟件包A之間存在依賴關系,這就意味著軟件包B 不能在缺少軟件包A的情況下運行。Recommends關系與D印ends關系相同,不過這里指出的依賴關系并不是強制必 須的。Suggests關系如果軟件包B與軟件包A之間存在Suggests關系(ASuggests B), 這就意味著軟件包A可以增強軟件包B的功能。但是在軟件包A缺少的情況下,軟件包B 仍然可以運行。Pre-Depends關系屬于安裝時依賴。如果軟件包B與軟件包A有Pre-D印ends關 系,表明軟件包B在安裝時需要軟件包A的支持。Enhances關系與Suggests關系相似,如果軟件包A與軟件包B有Enhances關 系,表示軟件包A可以增強軟件包B的功能。Conflicts關系表示軟件包間的沖突關系。如果軟件包A與軟件包B沖突,則軟 件包A與軟件包B不能在同一系統(tǒng)中共存。R印laces關系提供了一種能夠解決沖突的方法。如果軟件包A可以R印laces軟 件包B,則軟件包B就必須先從系統(tǒng)中移除,然后軟件包A才能被安裝。Provides關系表示虛包關系。本發(fā)明提出的基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML語言的統(tǒng)一建模方 法,包括以下步驟步驟10 解析軟件包中的依賴關系表示為統(tǒng)一軟件包元數(shù)據(jù)格式Package格式。如圖1所示為Linux軟件包間依賴關系提取過程圖,包括以下步驟步驟101 根據(jù)各種不同的Linux軟件包格式,從依賴關系建模的角度,提出一種 統(tǒng)一的軟件包元數(shù)據(jù)格式Package格式及其XML表示方法。首先進入步驟1011 根據(jù)各種不同的Linux軟件包格式,從依賴關系建模角度給 出統(tǒng)一軟件包元數(shù)據(jù)格式Package格式所包含的元素;然后執(zhí)行步驟1012 給出Package格式中所包含的元素的描述性定義;有各種不同的Linux軟件包格式,如Redhat Linux軟件包為rpm格式,Debian Linux為deb格式,軟件包也可以為tgz或pkg等格式,不同的軟件包格式包含的內(nèi)容也有 差異,不同軟件包格式的分析和對比如表1所示。在提取包間依賴關系時,需要針對不同的 包格式分別進行處理,每增加一種包格式,就需要對依賴關系建模構件的相應部分做出修 改,為使依賴關系建模構件獨立于各種不同的包格式,需要其輸入為一個統(tǒng)一的包元數(shù)據(jù) 格式,為此本發(fā)明從依賴關系建模角度提出一種統(tǒng)一的軟件包元數(shù)據(jù)格式,該元數(shù)據(jù)格式 只包含了依賴關系建模所需的必要信息。通過統(tǒng)一包元數(shù)據(jù)格式將不同格式軟件包信息的 解析、依賴關系提取與依賴關系建模構件分離,以增加各自的可擴展性。統(tǒng)一軟件包元數(shù)據(jù) 格式定義如表2所示。表1不同軟件包格式對比
權利要求
1.一種軟件包依賴關系建模方法,其是基于統(tǒng)一軟件包元數(shù)據(jù)格式和擴展的GraphML 語言的統(tǒng)一建模方法,其特征在于包括以下步驟步驟10 解析軟件包中的依賴關系表示為統(tǒng)一的軟件包元數(shù)據(jù)格式Package格式; 步驟20 將表示為統(tǒng)一軟件包元數(shù)據(jù)格式Package格式的依賴關系用擴展的GraphML 語言描述,并將其可視化。
2.根據(jù)權利要求1所述的一種軟件包依賴關系建模方法,其特征在于統(tǒng)一的軟件包元數(shù)據(jù)格式lockage格式是從依賴關系建模的角度提出,只包含了依賴 關系建模所需的必須信息;擴展的GraphML是基于GraphML,通過為其元素增加屬性和增加data元素內(nèi)容的方式 對其進行了擴展。
3.根據(jù)權利要求1所述的一種軟件包依賴關系建模方法,其特征在于其中所述的步驟 10還包括步驟101 根據(jù)各種不同的Linux軟件包格式,從依賴關系建模的角度,提出一種統(tǒng)一 的軟件包元數(shù)據(jù)格式Package格式及其XML表示方法;步驟102 根據(jù)輸入的軟件包格式,讀取此種軟件包格式的包基的軟件包文件或包基 的描述文件,解析并提取軟件包元數(shù)據(jù)的依賴信息;步驟103 將獲得的依賴信息轉(zhuǎn)換為統(tǒng)一軟件包元數(shù)據(jù)格式Package格式,并用XML表 示為統(tǒng)一軟件包元數(shù)據(jù)描述的包基描述文件。
4.根據(jù)權利要求3所述的一種軟件包依賴關系建模方法,其特征在于其中所述的步驟 101進一步包括步驟1011 根據(jù)各種不同的Linux軟件包格式,從依賴關系建模角度給出統(tǒng)一軟件包 元數(shù)據(jù)格式Package格式所包含的元素;步驟1012 給出Package格式中所包含的元素的描述性定義; 步驟1013 根據(jù)Package格式,給出Package格式的XML表示方法。
5.根據(jù)權利要求3所述的一種軟件包依賴關系建模方法,其特征在于其中所述的步驟 102進一步包括步驟1021 根據(jù)輸入的軟件包格式,判斷軟件包基的格式;步驟1022 根據(jù)包基的格式,讀取此種格式的包基的軟件包文件或包基的描述文件; 步驟1023 根據(jù)讀取的軟件包文件或包基的描述文件,解析并提取軟件包元數(shù)據(jù)的依賴信息。
6.根據(jù)權利要求3所述的一種軟件包依賴關系建模方法,其特征在于其中所述的步驟 103進一步包括步驟1031 將提取的軟件包元數(shù)據(jù)的依賴信息轉(zhuǎn)換為面向依賴建模的Package結(jié)構; 步驟1032 將lockage結(jié)構轉(zhuǎn)換為用XML表示的統(tǒng)一軟件包元數(shù)據(jù)描述的包基描述文件。
7.根據(jù)權利要求1所述的一種軟件包依賴關系建模方法,其特征在于其中所述的步驟 20還包括步驟201 基于包基建模需求,對GraphML進行擴展,得到擴展的GraphML格式; 步驟202 將Package結(jié)構轉(zhuǎn)換為擴展的GraphML文件格式描述,生成graphml. xml文件;步驟203 讀取graphml. xml并將其可視化。
8.根據(jù)權利要求3所述的一種軟件包依賴關系建模方法,其特征在于其中步驟101所 述的統(tǒng)一的軟件包元數(shù)據(jù),包含了依賴關系建模所需的必須信息,對不同格式的軟件包進 行統(tǒng)一軟件包元數(shù)據(jù)表示,統(tǒng)一軟件包元數(shù)據(jù)用XML表示。
9.根據(jù)權利要求3所述的一種軟件包依賴關系建模方法,其特征在于其中步驟102所 述的軟件包依賴關系提取過程,至少支持DEB、RPM、Cache和HDList四種格式文件的元數(shù)據(jù) 解析工作,轉(zhuǎn)換為面向依賴建模的Package結(jié)構。
10.根據(jù)權利要求7所述的一種軟件包依賴關系建模方法,其特征在于其中步驟203所 述的讀取擴展的GraphML文件并將其可視化,包含了對用擴展的GraphML文件描述的信息 用圖形化方式表示出來。
11.根據(jù)權利要求3所述的一種軟件包依賴關系建模方法,其特征在于其中所述的待 描述的軟件包的提取及解析過程為DEB軟件包的解析。
全文摘要
本發(fā)明提供了一種軟件包依賴關系建模方法,該方法包括解析軟件包中的依賴關系并表示為統(tǒng)一軟件包元數(shù)據(jù)格式Package格式;將表示為統(tǒng)一軟件包元數(shù)據(jù)格式Package格式的依賴關系用擴展的GraphML語言描述,并將其可視化。本發(fā)明對不同的軟件包管理系統(tǒng)進行建模,可以對可安裝軟件包依賴關系進行管理,可以提高軟件包依賴關系管理的效率,可以降低軟件包之間的依賴關系管理的復雜度。
文檔編號G06F9/44GK102109991SQ20101024113
公開日2011年6月29日 申請日期2010年7月30日 優(yōu)先權日2010年7月30日
發(fā)明者蘭雨晴, 匡明霞 申請人:蘭雨晴