999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

面向操作系統(tǒng)版本構(gòu)建的軟件包依賴關(guān)系分析*

2021-11-22 08:55:36俊,周凱,任怡,朱浩,秦瑩,王
計算機工程與科學 2021年11期
關(guān)鍵詞:分析系統(tǒng)

馬 俊,周 凱,任 怡,朱 浩,秦 瑩,王 靜

(國防科技大學計算機學院, 湖南 長沙 410073)

1 引言

軟件發(fā)行管理(Software Release Management)在大型軟件工程開發(fā)中的作用越來越重要[1],同時由于大型軟件組件構(gòu)建和相互關(guān)系復雜,經(jīng)常會由于某個組件的更新升級導致整個軟件系統(tǒng)失效或者崩潰[2]。操作系統(tǒng)作為最復雜的基礎(chǔ)軟件系統(tǒng)之一,其版本構(gòu)建和發(fā)行管理中面臨的這類問題更加突出。

近年來,Linux類操作系統(tǒng)在服務器和桌面領(lǐng)域愈發(fā)普及與流行,系統(tǒng)復雜性也隨著軟件規(guī)模的增加而劇增。至2020年,僅內(nèi)核代碼已經(jīng)超過2 500萬行,包含超過61 000個文件[3],而一個典型的Ubuntu發(fā)行版本對應軟件倉庫中開源軟件或組件的數(shù)量也超過3萬個,二進制軟件包數(shù)量超過6萬個。為了便于組織管理和維護,Linux系統(tǒng)中的應用軟件以特定格式的軟件包進行組織,通過軟件包的各種屬性描述軟件包之間的相互關(guān)系,并提供管理工具(如Ubuntu的DPKG和APT工具、CentOS的RPM和YUM工具等)便于用戶安裝、升級與卸載軟件。在軟件包的相互關(guān)系中,依賴關(guān)系主要體現(xiàn)了一個軟件的安裝和執(zhí)行依賴于另一個軟件提供的運行庫或服務接口等。操作系統(tǒng)在進行發(fā)行版本構(gòu)建時,除了依據(jù)必要功能選擇核心組件的軟件包,還必須將組件依賴的軟件包集成到版本中,提供一個依賴關(guān)系自洽的閉包。因此,依賴關(guān)系對于操作系統(tǒng)版本構(gòu)建和系統(tǒng)的定制裁剪至關(guān)重要。

從開源社區(qū)中Linux系列操作系統(tǒng)發(fā)行版本的組成來看,不同使用場景與功能特性需求的差異,會導致選取軟件包的范圍和數(shù)量不同。表1選取開源社區(qū)發(fā)行版本活躍度統(tǒng)計網(wǎng)站Distrowatch[4]上近3個月(2020.08~2020.11)點擊率排名靠前的操作系統(tǒng)進行分析,可以大致看出:以Ubuntu為基礎(chǔ)衍生出了眾多集成不同桌面環(huán)境和工具的桌面操作系統(tǒng)版本,而服務器操作系統(tǒng)版本則會選擇相對固定的桌面環(huán)境。進一步選取比較有代表性的Ubuntu和CentOS的不同版本對軟件包數(shù)量進行分析,如圖1所示,可以看出:桌面版本與服務器版本在軟件包的數(shù)量上存在非常大的差異。同時,由于很多的開源軟件更新頻繁,軟件之間的依賴等關(guān)系復雜,基于這些軟件包構(gòu)建的操作系統(tǒng)也要不斷迭代升級,從而使操作系統(tǒng)發(fā)行版本構(gòu)建的碎片化問題突出。因此,如何從軟件倉庫選取合適的軟件包,平衡軟件包數(shù)量與系統(tǒng)可靠性之間的關(guān)系是操作系統(tǒng)發(fā)行版本構(gòu)建和發(fā)布管理時需要重點關(guān)注的問題。

Table 1 Analysis on composition and characteristics of typical of operating system distribution表1 典型操作系統(tǒng)發(fā)行版本組成特點分析

Figure 1 Built-in packages of different Linux distributions圖1 不同發(fā)行版本默認包含的軟件包數(shù)量統(tǒng)計

目前,操作系統(tǒng)版本構(gòu)建主要是從工程實現(xiàn)角度基于歷史經(jīng)驗進行軟件包的選擇和集成,相應的理論分析和支持不足。本文通過依賴關(guān)系構(gòu)建軟件包之間的關(guān)系圖,建立了基于依賴關(guān)系的操作系統(tǒng)版本構(gòu)建模型,并通過對典型Ubuntu發(fā)行版本以及對應軟件倉庫的軟件包關(guān)系特征進行統(tǒng)計,結(jié)合功能分類進行分析,對模型有效性進行驗證的同時,總結(jié)了幾條操作系統(tǒng)版本構(gòu)建和系統(tǒng)裁剪定制的指導原則。

2 相關(guān)工作

軟件發(fā)行管理最早是由van der Hoek等人[1]提出的,并在2003年提出了基于組件的軟件發(fā)行管理,指出依賴是軟件發(fā)行管理的核心[5]。而依賴關(guān)系分析在大型軟件工程活動中也成為了重要研究熱點,覆蓋包括軟件理解、測試、調(diào)試、維護和開發(fā)等各個環(huán)節(jié)[6]。

依賴關(guān)系的建模方式主要包括利用結(jié)構(gòu)矩陣、SAT、特性圖以及復雜網(wǎng)絡等。Sangal等人[7]首次提出了依賴結(jié)構(gòu)矩陣DSM(Dependency Structure Matrix)模型,用于描述軟件構(gòu)件間的依賴關(guān)系。Laval等人[8]提出了EDSM(Enriched Dependency Source Matrix),通過擴展DSM能夠判斷出軟件包之間的循環(huán)依賴。類似研究還有設計結(jié)構(gòu)矩陣(Design Structure Matrix)[9]和域映射矩陣(Domain Mapping Matrix)等[11]。在開源操作系統(tǒng)的研究中,Wang等人[11]提出一種分析Linux操作系統(tǒng)發(fā)行包依賴關(guān)系圖的方法,從復雜網(wǎng)絡和復雜系統(tǒng)的角度對開源操作系統(tǒng)進行研究,將開源操作系統(tǒng)抽象為軟件網(wǎng)絡,并且從全局的角度來探索和發(fā)現(xiàn)開源操作系統(tǒng)的結(jié)構(gòu)特征與演化規(guī)律。葉安達[12]則用圖論思想分析源碼包之間的依賴關(guān)系,研究源碼包之間的拓撲關(guān)系,給出鏈式依賴關(guān)系的源碼包的最佳編譯順序。

從軟件包的依賴關(guān)系的研究目的來看,目前的研究主要包括:依賴關(guān)系改善、依賴關(guān)系提取、依賴完整性檢測[13]、包管理相關(guān)(安裝、升級、分發(fā))[14]和探究軟件系統(tǒng)生態(tài)等。其中改善與解決軟件依賴關(guān)系的研究主要關(guān)注SAT求解與軟件包關(guān)系管理。例如,顧昊等人[15]對軟件包依賴問題進行了分析與歸納,給出了該問題的形式化描述,并提出了一套將軟件包依賴問題轉(zhuǎn)變?yōu)?SAT問題的基本映射規(guī)則,最后結(jié)合MiniSAT給出了基本的求解算法。Mancinelli等人[2]則集中于包管理工具,通過探索給定包的依賴需求,執(zhí)行正確安裝所需的所有步驟,自動找到丟失的依賴包,并自動下載安裝這些包。

還有部分研究將依賴關(guān)系與相應系統(tǒng)軟件及其生態(tài)相結(jié)合。例如,聚焦于依賴關(guān)系相關(guān)的軟件包生態(tài)與演進的依賴關(guān)系分析[16],關(guān)注理解復雜系統(tǒng)中組件間的關(guān)系以更好地管理復雜軟件系統(tǒng)[4,17]等。

上述工作主要是以開源操作系統(tǒng)軟件包為元素的依賴關(guān)系分析,目的是評估系統(tǒng)的兼容性,便于進行軟件包的組織管理,很少有直接面向操作系統(tǒng)版本構(gòu)建和定制裁剪的分析與研究。

在操作系統(tǒng)版本構(gòu)建和定制裁剪方面,標準化組織與產(chǎn)業(yè)界在工程實踐中積累了很多經(jīng)驗和行之有效的規(guī)則。從系統(tǒng)構(gòu)建來看,Debootstrap[17]可以用來構(gòu)建最小系統(tǒng)集合,維持最基本的系統(tǒng)功能運行,開發(fā)者可以基于最小系統(tǒng)通過增加軟件包及其依賴定制構(gòu)建版本。從軟件包的選擇來看,Linux為代表的開源社區(qū)將軟件包進行分級,例如Ubuntu的Priority屬性將軟件包分為Required、Important等不同優(yōu)先級以區(qū)分軟件包在系統(tǒng)中的必要程度,系統(tǒng)構(gòu)建時可以根據(jù)需要選擇不同等級的軟件包。Red Hat為此建立一個用來區(qū)分軟件包兼容程度的分層框架,根據(jù)軟件包的演化兼容情況劃分了4個兼容性等級[18],指導開發(fā)者選擇開發(fā)依賴的組件,并且在最新的8.0版本中通過引入AppStream對不同功能的包劃分管道進行分類選擇和管理[19]。總的來看,版本構(gòu)建領(lǐng)域長久以來工程實踐的經(jīng)驗都先于理論分析的指導。

3 基于依賴關(guān)系的版本構(gòu)建模型

操作系統(tǒng)版本構(gòu)建過程一般是基于一個初始的軟件包列表,根據(jù)依賴關(guān)系把相關(guān)的支撐軟件包集成,最終構(gòu)建為一個版本鏡像提供給用戶進行安裝使用。從圖論角度來看,軟件包及其依賴關(guān)系構(gòu)成了復雜的有向圖,通過分析有向圖的特性可以在一定程度上了解軟件包依賴關(guān)系的規(guī)律。為更好地分析軟件包依賴關(guān)系與操作系統(tǒng)版本構(gòu)建之間的聯(lián)系,以及操作系統(tǒng)版本構(gòu)建的過程和原理,本文給出基于依賴關(guān)系的操作系統(tǒng)版本構(gòu)建模型。

依賴關(guān)系主要體現(xiàn)在軟件包之間,因此下面給出操作系統(tǒng)的軟件包依賴關(guān)系的定義:

定義1(軟件包依賴關(guān)系) 依賴關(guān)系用一個二元組eij=(vi,vj)表示,即軟件包vi依賴軟件包vj,等價于如果要安裝軟件包vi,需要提前或同時安裝vj。

在軟件包依賴關(guān)系模型的基礎(chǔ)上,定義依賴關(guān)系圖模型如定義2所示:

定義2(依賴關(guān)系圖) 依賴關(guān)系圖模型是一個二元組G=(V,E),表示一組軟件包節(jié)點及其依賴關(guān)系,其中V表示軟件包節(jié)點的集合,E表示V中節(jié)點之間的依賴關(guān)系的集合。

通過軟件包依賴關(guān)系和依賴關(guān)系圖的定義,可以更好地描述操作系統(tǒng)版本和對應的軟件倉庫。軟件倉庫通常用于對特定版本或者應用場景所需要的一系列軟件包進行組織管理,可以包含操作系統(tǒng)發(fā)行版本沒有默認集成的各種軟件包。軟件包倉庫定義如定義3所示:

定義3(軟件倉庫) 用二元組Grespo=(Vall,Eall)表示一個操作系統(tǒng)發(fā)行版本對應的軟件倉庫,其中,Vall表示當前操作系統(tǒng)發(fā)行版本支持的所有軟件包,Eall表示依賴關(guān)系的集合。

為方便論述,將軟件包vi依賴的軟件包的集合用D(vi)表示,且?vj∈D(vi),?eij=(vi,vj)。與軟件倉庫模型相比,操作系統(tǒng)特定版本模型多了一組限定條件,其定義如定義4所示:

定義4(操作系統(tǒng)發(fā)行版本) 用二元組Gdist=(Vdist,Edist)表示一個操作系統(tǒng)發(fā)行版本,其中Vdist表示當前操作系統(tǒng)發(fā)行版本中集成的所有軟件包,Edist表示依賴關(guān)系的集合。

上述4個定義從軟件包及其依賴關(guān)系角度描述了操作系統(tǒng)發(fā)行版本與對應的軟件倉庫模型。從定義可知Gdist?Grespo。由于發(fā)行版本必須保證自帶的所有軟件包都能夠正常安裝運行,因此很容易得到操作系統(tǒng)發(fā)行版本的依賴關(guān)系滿足完備性。

定理1(發(fā)行版本依賴關(guān)系完備性) 給定操作系統(tǒng)發(fā)行版本Gdist=(Vdist,Edist),?vi∈Vdist,D(vi)?Vdist。

發(fā)行版本依賴關(guān)系的完備性保證了發(fā)行版本自身可以獨立完成安裝和運行,而不需要額外的軟件倉庫支持。在開源操作系統(tǒng)發(fā)展的早期,由于光盤容量限制,有些發(fā)行版本會將操作系統(tǒng)的安裝鏡像保存在一張光盤中,而將包含其依賴的軟件倉庫保存在另外一張或者多張光盤中,在這種情況下,發(fā)行版本的概念是同時包含了安裝光盤和軟件倉庫光盤。

從上述定義和定理也可以知道,操作系統(tǒng)發(fā)行版本的軟件包集合根據(jù)功能需求的不同,其大小范圍也會有差異。其基本的構(gòu)建過程通常是基于一個初始的基礎(chǔ)軟件包列表將每個包依賴的軟件包都集成進來,如此不斷迭代,形成完備的軟件包集合。其中比較關(guān)鍵的一步就是根據(jù)依賴關(guān)系把相關(guān)的支撐軟件包找到,為了簡化流程,將該步驟封裝,本文提出軟件包依賴析取算法PullDepends。

算法1軟件包依賴析取算法PullDepends

輸入:vi。//package

輸出:V。//a group of packages

PullDepends(vi)

1.V={};

2.Vnext=D(vi);

3.forvjinVnext

4.ifvjnot inV

5.V=V∪{vj};

6.Vnext=Vnext∪D(vj);

7.returnV.

PullDepends的主要思路是通過循環(huán)檢測獲取安裝特定軟件包所需的所有軟件包的集合。輸入一個軟件包,得到軟件包集合D(vi)并遍歷,繼續(xù)得到這些軟件包的支撐軟件包,最終該算法返回一個軟件包的集合V,V為安裝特定軟件包vi所需要的所有依賴軟件包的集合。

該算法是通過Vnext的動態(tài)變化避免了遞歸調(diào)用和重復性判斷,從算法的執(zhí)行過程來看,D(vi)實際上是從vi出發(fā)的依賴關(guān)系樹的所有子節(jié)點,因此上述算法的效率與該依賴關(guān)系樹的深度有較大的關(guān)聯(lián)。為此,引入依賴深度的概念。

定義5(依賴深度) 軟件包的依賴深度用Depth(vi)表示,Depth(vi)=maxvj{distance(vi,vj)}。

依賴深度可以反映一個軟件包在操作系統(tǒng)構(gòu)建中所處的維度層次,對于版本構(gòu)建時軟件包的選擇以及版本構(gòu)建算法的分析具有重要參考意義。

基于上述軟件包依賴析取算法可以實現(xiàn)基于依賴關(guān)系的版本構(gòu)建算法BuildSystem。該算法的輸入為一組特定軟件包集合V0,這些軟件包是構(gòu)建操作系統(tǒng)版本需要的基礎(chǔ)軟件包列表集合。V是通過依賴關(guān)系獲得的所有需要增加的軟件包集合,所有V的集合最終組成一個特定的推薦操作系統(tǒng)發(fā)行版本S。

算法2版本構(gòu)建算法BuildSystem

輸入:V0。//a group of packages including base packages and specific packages

輸出:S。//a specific operating system version

1.V={};

2.forvkinV0

3.Vk=PullDepends(vk);

4.V=V∪Vk;

5.ReturnS=V0∪V.

4 基于依賴關(guān)系的版本構(gòu)建分析系統(tǒng)

第3節(jié)中的定義和模型為分析版本構(gòu)建過程提供了理論依據(jù)。本節(jié)將以此為基礎(chǔ),以典型操作系統(tǒng)版本和軟件倉庫的軟件包及依賴關(guān)系數(shù)據(jù)為依據(jù),設計和實現(xiàn)一套基于依賴關(guān)系的版本構(gòu)建分析系統(tǒng),并根據(jù)系統(tǒng)分析統(tǒng)計的結(jié)果與實際發(fā)行版本的組成進行比較,從而分析總結(jié)出典型版本構(gòu)建的規(guī)律。

基于依賴關(guān)系的版本構(gòu)建分析系統(tǒng)總體結(jié)構(gòu)如圖2所示。該系統(tǒng)主要由數(shù)據(jù)解析模塊、數(shù)據(jù)分析模塊和數(shù)據(jù)展示模塊3部分構(gòu)成。

Figure 2 Analysis system for distribution building based on dependency relationship圖2 基于依賴關(guān)系的版本構(gòu)建分析系統(tǒng)

4.1 數(shù)據(jù)來源

本文以優(yōu)麒麟開源操作系統(tǒng)18.04版本為例,選取該版本在倉庫中的信息列表,并將數(shù)據(jù)持久化到軟件倉庫數(shù)據(jù)庫中。同時選取Ubuntu桌面版和服務器版等典型版本軟件包數(shù)據(jù)作為對比驗證的數(shù)據(jù)來源。

4.2 數(shù)據(jù)解析模塊

數(shù)據(jù)解析模塊實現(xiàn)從外部數(shù)據(jù)解析導入到本地數(shù)據(jù)庫的過程。為記錄描述軟件包及依賴關(guān)系的數(shù)據(jù),本文設計構(gòu)建了3個數(shù)據(jù)庫表,如表2所示。其中,Package表存放所有的軟件包信息,即Vall;Relation表存放提取出來的關(guān)系,對應模型中的Eall;Degree表存放解析后的數(shù)據(jù),包括出入度等屬性。

圖3是數(shù)據(jù)解析的主要流程。首先從優(yōu)麒麟的軟件倉庫中提取相關(guān)字段并保存到Package表中,該表存儲軟件倉庫中所有軟件包信息。然后提取記錄中的依賴關(guān)系并逐條保存到Relation表中。最后利用python中的networkx庫實現(xiàn)已有信息的解析,得到諸如出度、入度和依賴深度等屬性并存入Degree表中。對于2個實驗操作系統(tǒng)版本,主要提取系統(tǒng)中已有軟件包的信息。

Figure 3 Process of dealing dependency realtionship圖3 數(shù)據(jù)解析過程

4.3 數(shù)據(jù)分析模塊與展示模塊

本文主要利用統(tǒng)計分析方法,重點對優(yōu)先級、所屬類別屬性、出入度和依賴深度等屬性和特性進行統(tǒng)計分析和對比驗證,并結(jié)合模型算法對版本構(gòu)建過程進行模擬比較。

數(shù)據(jù)展示模塊主要包括數(shù)據(jù)可視化,并借助自動化腳本且結(jié)合已有知識庫進行人工分析。其中可視化部分利用python批量生成特定gephi格式文件,并通過Gephi工具與Echart進行結(jié)果展示。

5 實驗與結(jié)果分析

5.1 數(shù)據(jù)統(tǒng)計

本文統(tǒng)計的系統(tǒng)軟件倉庫包括60 861個軟件包節(jié)點和250 608條軟件包之間的依賴關(guān)系,并以此為基礎(chǔ)進行關(guān)鍵特性的統(tǒng)計分析。

5.1.1 基于軟件包入度的統(tǒng)計

軟件包的入度表示該軟件包被其他軟件包依賴的次數(shù),入度越大,該軟件包被依賴的次數(shù)越多。入度在很大程度上也是軟件包對其他軟件影響程度的一個體現(xiàn)。從版本構(gòu)建上來說,對其他軟件包影響比較大的軟件包應該盡量集成到版本中。圖4所示是整個軟件倉庫中軟件包的入度總體分布情況。

Figure 4 Statistic graph of in_degree圖4 入度區(qū)間分布統(tǒng)計圖

從圖4中可以看出,超過95%的軟件包入度都集中于10以下,特別是入度為0的軟件包超過了一半,這類軟件包通常都是直接面向用戶提供服務的軟件或者組件。另外有少數(shù)軟件包的入度特別大,甚至超過1 000,這些通常都是操作系統(tǒng)版本制作需要重點關(guān)注和默認集成的。為進一步分析這類軟件包的情況,本文統(tǒng)計了入度超過2 000的軟件包,如表3所示。

Table 3 Software packages with in_degree more than 2000表3 入度超過2 000的軟件包

這些軟件包基本上都是系統(tǒng)組成最基礎(chǔ)的庫或者語言解釋支持。如libc6包,它包含了標準C庫的共享版本,被操作系統(tǒng)中近1/3的軟件包直接依賴,是幾乎所有的程序都會使用的標準庫。其他大部分軟件包為lib庫,為系統(tǒng)重要基礎(chǔ)軟件如C語言編譯器、x11等提供函數(shù)庫,如libstdc++6、libgcc1為源碼包gcc-8構(gòu)建的c++庫和gcc支持庫。

5.1.2 基于軟件包出度的統(tǒng)計

軟件包的出度表示該軟件包依賴其他軟件包的數(shù)目,出度大則表示其依賴的軟件包多。從軟件包的發(fā)行維護來說,它依賴的軟件包中任意一個出現(xiàn)變動,如版本的變化或者軟件包內(nèi)部函數(shù)名的變更等,都可能導致該軟件包出現(xiàn)兼容性問題,因此在版本構(gòu)建和軟件包維護過程中應該重點關(guān)注。如圖5所示為系統(tǒng)軟件包出度的分布統(tǒng)計。

Figure 5 Statistic graph of out_degree圖5 出度分布統(tǒng)計圖

與入度相比而言,出度的分布跨度要小很多,最大出度不超過200,超過98%的軟件包的出度在20以內(nèi),也間接表明了軟件設計的一個要求,軟件包內(nèi)部緊密連接,軟件包之間松耦合。從統(tǒng)計來看,出度在0~5的軟件包數(shù)量比較多,這與開源軟件本身提供的開發(fā)庫相對分散和多樣有關(guān),也是當前開源生態(tài)建立和維護比較困難的重要因素。

通過對出度超過100的軟件包分析發(fā)現(xiàn),出度大的軟件包一般都是偏應用層面的軟件包,如桌面環(huán)境、瀏覽器的測試組件等,作為非必須安裝項,可由用戶根據(jù)自身需求進行選擇。安裝這類軟件的同時也需要安裝大量的依賴軟件包,這也是桌面版本通常都比服務器版本的軟件包數(shù)量多的主要原因。

5.1.3 依賴深度的統(tǒng)計

軟件包的出度通常反映其直接依賴的軟件包情況,而被依賴軟件包的下一級依賴關(guān)系則由被依賴軟件包進行維護,這種管理方式減少了軟件安裝時依賴的檢測判斷,但也給軟件的正常執(zhí)行埋下了隱患。例如某一級軟件包的依賴關(guān)系出現(xiàn)異常難易被上一級的軟件包檢測。目前版本構(gòu)建過程缺少對多級依賴關(guān)系的直觀衡量,而依賴深度可以作為參考。

表4是依賴深度排名前10的軟件包數(shù)據(jù)統(tǒng)計。目前統(tǒng)計的軟件倉庫中軟件包依賴深度最大不超過20,而且依賴深度大的軟件包主要是偏上層應用的軟件。

Table 4 Statistics of top 10 dependency depth表4 依賴深度前10的統(tǒng)計

從版本構(gòu)建來看,某個軟件包的依賴深度越大,將其引入版本中時需要構(gòu)建的軟件棧就會越長,會導致版本的管理維護越復雜,特別是軟件棧中間組件版本變化對整個系統(tǒng)兼容性的影響也會越大,這也是目前開源發(fā)行版本碎片化嚴重的一個原因。因此,版本的構(gòu)建應該盡量選擇依賴深度較小的軟件包。

5.1.4 基于軟件包優(yōu)先級的統(tǒng)計

包的優(yōu)先級完全由它直接提供給用戶的功能決定,優(yōu)先級高的軟件包通常只會被同級別優(yōu)先級與低級別優(yōu)先級軟件包所依賴,換而言之,優(yōu)先級高的包將處于依賴關(guān)系圖中偏底層的位置。如表5所示展示了優(yōu)麒麟軟件倉庫中軟件包的優(yōu)先級和在系統(tǒng)中所占比重。

Table 5 Number distribution of software packages with different priorities表5 不同優(yōu)先級的軟件包數(shù)量分布

從平均入度來看,Required類型的平均入度遠高于其他類型優(yōu)先級,其次Important優(yōu)先級的平均入度為151.39,優(yōu)先級的平均入度也與優(yōu)先級的劃分相對應:優(yōu)先級越高,入度越高,被依賴的程度越深。同樣,平均出度作為當前類別軟件包依賴其他軟件包的平均程度,也表明Required類型軟件包作為必備軟件包在系統(tǒng)中一般都是被依賴的角色。在操作系統(tǒng)版本構(gòu)建中,Required和Important類型優(yōu)先級的軟件包通常需要首先被開發(fā)者考慮。

5.2 典型系統(tǒng)印證

本文選擇Ubuntu-18.04.5-live-server-amd64(以下簡稱服務器版本)和Ubuntu-18.04.5-desktop-amd64(以下簡稱桌面版本)2個版本進行驗證。

5.2.1 依賴出入度與版本構(gòu)建關(guān)系

圖6所示為不同范圍入度的軟件包系統(tǒng)中所占比重。從圖6中可以看到,操作系統(tǒng)中軟件包的入度從0~50到大于1 000都有分布,并且系統(tǒng)中入度小于50的軟件包占所有軟件包80%左右,這類軟件包即使入度不是很高,但也為系統(tǒng)的正常運行提供重要支撐。

Figure 6 Proportion of software packages in different in_degree intervals in systems圖6 不同入度區(qū)間軟件包數(shù)量在系統(tǒng)中所占比重

在出入度為0的軟件包中,服務器版本含有4個,包括崩潰檢測報告功能的相關(guān)腳本、bash的補充工具、krb5的語言包和ncurses-base。桌面版本中額外多了字體、主題等相關(guān)的軟件包。因此,單個軟件包的入度低并不能說明該軟件包對系統(tǒng)不重要。在入度超過1 000的13個軟件包中,與軟件倉庫相比,桌面版本缺少2個編程類庫包,服務器版本缺少3個編程語言類軟件包和qt5核心軟件包。語言類軟件包如python、ruby等由于本身廣泛的使用而有著極高的出入度,但對于構(gòu)建一個基礎(chǔ)系統(tǒng)來說并不是必需考慮的軟件包。

結(jié)論1單個軟件包的出入度不能作為衡量系統(tǒng)版本能否正常運行的指標,但高入度的軟件包依舊是版本構(gòu)建需要重點關(guān)注的。入度為0的軟件包通常是直接向用戶提供功能的組件,在系統(tǒng)構(gòu)建時可以根據(jù)功能需求進行選擇。

5.2.2 優(yōu)先級分類與版本構(gòu)建關(guān)系

圖7展示了2個實驗版本不同優(yōu)先級下的軟件包數(shù)量。2個系統(tǒng)中,Required、Important和Standard 3種優(yōu)先級的軟件包數(shù)量與軟件倉庫一致,系統(tǒng)中軟件包數(shù)量的差異主要體現(xiàn)在Optional與Extra中軟件包的不同。在服務器版本中,Extra的軟件包主要與云實例功能模塊相關(guān)。Optional中的軟件包主要有l(wèi)ib和python 2類軟件包,其中l(wèi)ib主要是優(yōu)先級高的軟件包支持庫,python類別軟件包則提供了核心組件的python接口和功能模塊。這2類軟件包為系統(tǒng)中必要功能模塊提供支持,需要根據(jù)實際情況進行選擇。

Figure 7 Classification of software packages with different version圖7 不同版本的軟件包分類

結(jié)論2在系統(tǒng)版本構(gòu)建過程中,根據(jù)系統(tǒng)基礎(chǔ)功能需求,優(yōu)先級為Required、Important和Standard的軟件包通常會加入版本,其他屬性的軟件包可以根據(jù)需求功能自由選擇。如果是做精簡定制裁剪,一些常用的命令工具則可以根據(jù)情況裁剪,因此針對系統(tǒng)裁剪需要提供更詳細的分類標記。

6 結(jié)束語

本文從依賴關(guān)系角度對操作系統(tǒng)版本構(gòu)建過程建立了基礎(chǔ)模型,并以優(yōu)麒麟18.04軟件倉庫的實際數(shù)據(jù)和Ubuntu典型服務器及桌面2個版本的實際數(shù)據(jù)為參考,進行了軟件包依賴關(guān)系出入度、優(yōu)先級和依賴深度等屬性的統(tǒng)計和對比驗證,總結(jié)給出了出入度、優(yōu)先級等屬性對版本構(gòu)建的影響規(guī)律,對于操作系統(tǒng)研發(fā)和版本構(gòu)建人員具有一定的指導意義,也為從理論上進行版本的自動分析和大規(guī)模軟件包的屬性及標記分析奠定了基礎(chǔ)。

從實際分析來看,軟件包的出入度在一定程度上依賴于軟件包開發(fā)和維護人員的經(jīng)驗,可能存在冗余依賴或者缺少依賴的問題,后續(xù)將結(jié)合依賴深度和優(yōu)先級等屬性和標記,對軟件包的屬性標記規(guī)律和準確性進行挖掘分析,并結(jié)合典型軟件包及CentOS等更多典型操作系統(tǒng)版本的演化進行數(shù)據(jù)分析,為操作系統(tǒng)版本構(gòu)建和裁剪、軟件兼容性評估以及故障關(guān)聯(lián)性分析等提供理論和數(shù)據(jù)支撐。

猜你喜歡
分析系統(tǒng)
Smartflower POP 一體式光伏系統(tǒng)
WJ-700無人機系統(tǒng)
隱蔽失效適航要求符合性驗證分析
ZC系列無人機遙感系統(tǒng)
北京測繪(2020年12期)2020-12-29 01:33:58
基于PowerPC+FPGA顯示系統(tǒng)
半沸制皂系統(tǒng)(下)
電力系統(tǒng)不平衡分析
電子制作(2018年18期)2018-11-14 01:48:24
連通與提升系統(tǒng)的最后一塊拼圖 Audiolab 傲立 M-DAC mini
電力系統(tǒng)及其自動化發(fā)展趨勢分析
中西醫(yī)結(jié)合治療抑郁癥100例分析
主站蜘蛛池模板: 在线综合亚洲欧美网站| 欧美精品1区2区| 免费观看无遮挡www的小视频| 欧美特级AAAAAA视频免费观看| 国产剧情无码视频在线观看| 久久精品无码专区免费| 98精品全国免费观看视频| 国产综合无码一区二区色蜜蜜| 日本手机在线视频| 一级毛片不卡片免费观看| 婷婷综合在线观看丁香| 在线观看国产小视频| 国产乱码精品一区二区三区中文| 亚洲精品在线影院| 国产区成人精品视频| 亚洲成aⅴ人片在线影院八| 国产一区免费在线观看| 亚洲AV无码乱码在线观看代蜜桃| 日韩专区第一页| 日韩精品一区二区三区中文无码| 亚洲 欧美 日韩综合一区| 日本少妇又色又爽又高潮| 丰满人妻中出白浆| 久久综合伊人 六十路| 精品撒尿视频一区二区三区| 午夜无码一区二区三区| 人妻无码中文字幕一区二区三区| 99久久人妻精品免费二区| 亚洲天堂在线免费| 国产成人免费| 国产福利影院在线观看| 亚洲欧美日本国产专区一区| 亚洲黄网在线| 日本免费福利视频| 国产丝袜丝视频在线观看| 欧美第二区| 无码'专区第一页| 极品国产一区二区三区| 国产欧美精品一区二区| 思思99热精品在线| 直接黄91麻豆网站| 欧美一区二区人人喊爽| 亚洲无码视频喷水| 狠狠操夜夜爽| 国产区精品高清在线观看| 免费看a毛片| 亚洲国产精品VA在线看黑人| 日韩欧美中文字幕一本| 亚洲第一成年网| 中文无码精品A∨在线观看不卡| 午夜福利视频一区| 第九色区aⅴ天堂久久香| 九色在线视频导航91| 日本三级精品| 欧美国产成人在线| 人妻精品久久久无码区色视| 久久久久久尹人网香蕉| 亚洲乱码精品久久久久..| 最新亚洲人成网站在线观看| 亚洲日韩精品无码专区97| 2021国产精品自产拍在线| 一级毛片在线播放| 国产成人91精品| 国产精品污视频| 国产成人免费手机在线观看视频| 国产精品大白天新婚身材| 青青青国产免费线在| 操国产美女| 国产一级毛片网站| 免费人成视网站在线不卡| 色综合五月婷婷| 精品国产污污免费网站| 91 九色视频丝袜| 成人午夜免费观看| 九九热视频精品在线| 亚洲人成网站日本片| 国产不卡一级毛片视频| 天天综合网色中文字幕| 视频在线观看一区二区| 国产凹凸视频在线观看| 日本一区二区三区精品视频| 免费激情网站|