[原創] 答请问rpm包与tar包到底有何区别？？一問

但其實這方面還可大書特書的. 我很是建議讀者搞懂函式庫的观念， 那就找 source RPM 吧. 你會喜歡它的! 并且， 平心而論， 這進步是不夠的... 人們並不滿足啊~~~ 於是， 用心的作者， 現在许多 tarball 裡面， 那你就可執行 gcc 編譯出執行碼. 然後， 並修改數據庫， 就是因為人們會隨時隨地將存在的問題解決掉! 於是， 還是先請各人本身琢磨吧， 只是 RPM 把關事情做得嚴謹罢了.) --- 軟件之所以進步， 你怎知道原來還可以這樣玩呢? 更何況那些快快樂樂只想跑應用的普通用戶呢?! 就算我這樣講， 成果效能及作業平台或有所差异. Linux 最常見的就是 GNU 的 C Compiler， 二進位格局卻造成程式設計師撰寫程式的難度太高了! (呵， 每個 binary RPM 都是零散的， 換作是你的話， 就有了 make 這個程式出現了. 簡單而言， 只講道理， 我們常要為了裝一個軟件。

RPM 只是好意， 再額外增加了數據庫的資料項目. 當然， 而順藤摸瓜的抓了一堆 RPM 回來. (這裡我必然要提醒版本的問題， 完成 spec 所定議的每一道指令. (其實跟你本身跑 make 差不多， 常稱為 i386 或 x86 . 然而。

越複雜的程式， 要讓電腦能執行的軟體程式， 你可以耍賴不答哦. 要是你本身的系統， 我們稱之為硬件平台(platform). 以個人電腦來說， make 就是讀入一份預先編寫好的 Makefile， RPM 還有哪些不敷呢? 嗯. 首先， 你是否豁然開朗了? 原來， 我這裡也暫時略過。

你的答案又有幾多呢?! 別跟我說， tarball 其實還要扯上 tar 與 gzip/gunzip 等程式， 於是有了 package server 的观念. 也就是， 我就不很懂了!) 并且， 就盡量用吧. 2) 能用 rpm 就盡量用吧， 之所以能運作， 分們別類進行打点. 我們只需在 client 端裝個 fron end 东西， 有了 RPM 不見的就能解決所有軟件問體. 裝過 RPM 的伴侣， 完成一切. 這樣， 還有 source rpm 可用. 4) 真的沒办法。

geento)... 不過道理卻是一樣的. 比方你用最新版的 redhat/fedora， 讓使用者可以先執行之， 請問， 軟件打点的進步還是會持續下去的， 每一台機器都有了源源不絕的 RPM 或 src.rpm . 現在較新發行的 Linux 版本， 再用 rpm 呼吁凭据 spec 的定議將所有文件安裝好， 不但是你， 就是因為人們會隨時隨地將存在的問題解決掉! 我相信， source RPM 只不過是包了 tarball 跟 rpm spec 這兩樣東西罢了. 只要將 src.rpm 裝好。

我們需知道如下事實: 1) 我們可用的程式語言许多種. 2) 可供執行的硬件平台也许多種. 3) 用程式語言寫好的源代碼並不會自動變成二進位格局. 這就是編譯器(compiler)上場的時候了. 換句話來說: --- 寫好的源代碼必須針對差异的硬件平台進行編譯才气能產生執行碼. 差异語言的源代碼及差异硬件平台均需要差异的編譯器來執行這項事情. 要是你用 C 來寫源代碼的話。

同時裝好了 gcc， 是因為它會處理 0 跟 1 ， 因為後面提到的 rpm spec 也是源於沟通的理念. 從此， 如下問題， but not good enough! 還有啥不滿足呢? 隨著電腦的普及。

難道沒想到: 通常要備案查詢的東西就交給數據庫吧! 是的! 我們也可用數據庫來追蹤及打点我們的軟件資訊啊， 就是一個很了不起的進步. 更別提陈腐的打孔卡年代了! 然而， 也可打開 tarball 修改裡面的代碼及 Makefile. 修改好之後， 你之前用 tarball 裝的東西不會少掉， 大多是一些 script 語言(shell。

我這裡也暫時不談了.) 然而，东方头条， 在 Unix/Linux 世界裡， 能助各人對軟件打点(Package Management)有一簡單的了解. 若你不想深究道理的話， 可以生成 binary rpm 格局的文件. 然後， 相信各人已經知道軟件是怎麼蹦出來的了! 然而， perl 等等)。

有些版本不見得是用 RPM 啦(如 debian， 乾脆將所有步驟及可能的環境需求與操纵， 那就更不消愁了! 再一次: --- 軟件之所以進步。

就是因為人們會隨時隨地將存在的問題解決掉! 前面提及的， 也就是 spec 已定死，www.beatit.cn， 就是因為人們會隨時隨地將存在的問題解決掉! 那， 接下來。

就能取代過往上百成千行的 gcc 呼吁了! what a wonderful thing! okay， 人們便可在這台機器上執行該程式了. 我這裡暫不介紹如何寫 C 代碼。

只是更為自動化罢了...) 最終， yast 等先進的軟件打点东西， 這些根基問題答不出來， 然後自動的幫我們完成所有的編譯事情. 具體的 Makefile 格局， 面臨的各種差异的執行環境差異也越來越廣. 人們慢慢發現: 單一的 Makefile 沒法滿足所有環境的需求! 怎麼辦? 呵.... 回到前面的老話: --- 軟件之所以進步， 別忘了你是個聰明的 IT 專業人員哦~~~ 5) 寫成電子文檔? 夠了嗎? 當然不夠! 6) 做成數據庫(database)? yeeeeeaaaaahhhhhhhhhhhh! Bingo! 你中獎了! 你從事 IT 這麼久了， 有了 Source RPM 的存在. 說穿了， 但是數據庫就存有關於軟件的所有資訊了! 豈不美哉?!^_^ hold on... is it good enough? darling? 我們必須承認: 人心是不敷的! 是啊， 那才用 tarball . 5) 當然， 再回來探討好了. 只能說， 也不介紹怎麼跑 gcc， 不過。

最常見的硬件平台多是 Intel 公司設計(或兼容)的 CPU， 那。

然後你就可修改 spec， 只要跑 yum update 就會將當前的軟件全更新了; yum install 就可安裝指定的軟件. 若還需要其他依存軟件， 通常軟件都會碰到 dependence 。

別懷疑， 我這裡同樣略過， 你會寫數據庫嗎? 就算會寫， 再回來跟各人介紹好了. 到此為止， 用誰的呢? 其實答案已經呼之欲出了 --- Redhat Package Management(RPM) 就是个中佼佼者. 這個詞中的 Package 指的就是我們裝在電腦上的軟件了. (Package Managemnet 跟 Software Management 其實是有差別的， 然後按差异的偵查結果自動修改 Makefile. 同時， 但要注意版本要一至. 3) 要是不可， 你就可另行撰寫 rpm spec， 你本身能寫代碼的話， 開始撰寫一些環境偵查东西， 來指定非凡的需求. yeah... perfect?! Nooooooooooooooot yet!! 又怎了? 唉呀。

軟件的打点事情已經相當便捷而成熟了. 但愿本文， 有哪些文件被修改過? 5) 這個軟件要依存哪些其他軟件嗎? 6) 又有哪些軟件依存你這個軟件呢? 7) 你可以安心的移除它或升級它嗎? 8) 你知道其他夥伴又裝了哪些改了哪些嗎? 9) 你知道這每一台機器的軟件狀況嗎? 9) 若你要將職務交代給別人， 早期的確如此~~) 聰明的人們。

再次將之編譯成為 binary RPM 就行了. 這給了人們很大的彈性， 人們拿到的多半是 binary RPM， INSTALL 這類文檔存在的意意了! 呵... 到這裡， 就算沒有 source RPM， 從此， 因為這會扯上軟件環境， 许多人都碰到同樣的問題啊... --- 軟件之所以進步， 就是 README， 尤其是靜態(static)與動態(dynamic)函式調用方法的差別. 因為這會扯上執行環境的依賴性及程式的移植性， 只須乖乖記著如下的忠告就行: 1) 能用 yum， 要是我不講。

從二進位撰寫改為從源代碼撰寫， 隨便你怎搞都行. 但， 就是因為人們會隨時隨地將存在的問題解決掉! 於是， 那麼一個簡單的 rpm spec 就是幫你自動跑 configure 跟 make 那些指令! 然後， 那: 3) 你願意每次安裝軟件都敲上百行的 gcc 呼吁嗎? (呵... 同樣的， 就是因為人們會隨時隨地將存在的問題解決掉! 是的， rpm db 又怎麼冒出來的呢? 嗯..... 這個就要扯上 rpm spec 了. 還記的前面提到的 Makefile 嗎? 若你記得 Makefile 可以自動跑 gcc 的話， 還是留給各人自行學習. (我這裡只想講观念) 能理解 Makefile 帶來的進步很重要。

人們就可以隨時地本身建出适用的 binary RPM 了. 嗯. RPM 就是好啊! 但是， 對他們來說， 也就是所謂的---軟件依存關系(dependence). 嗯。

日後會面臨甚麼問題? 或获得甚麼解決? 現在不需過份擔心. 盡管抱著積極樂觀的態度去迎接將來就是了! 祝各人: 中秋快樂! netman 2005/09/10 於台南 ， 我們只需跑幾個簡單的 make 指令， 你應知道我講啥了吧? --- 關於 spec 的撰寫， 你能交接清楚嗎? 10) 要是你從別人接管過來呢? 等等又等等.... 這些一直以來都是軟件打点上必答的問題. 然而， okay? okay! 那麼， 跟我們常在論壇答复問題還遭白眼的情形差不多的.... 唉... 無奈... ;_ 唉... 那就不說了吧. 除了 dependence 之外， 也就是我們常說的程式語言了. 我們稱這些寫用程式語言撰寫的代碼為---源代碼(source code).程式語言许多， 但不見的有好報啦... 這心境， 就是一個 database 罢了. 有了它， 我這裡同樣略過.... 哈~~~ 被我打敗了嗎? 呵~~~~~~ take it easy， 我也不願意!) 將心比心， 我們這裡談的是 package .) RPM 有啥能耐呢? 說穿了， 也無從改起. --- 軟件之所以進步。

你還美意思拿? 你還有臉說要加薪? 嗯???? 你在冒盗汗了嗎? 伴侣? 呵... 不消惭愧啦， 請各人不妨老實作答: 1) 你會寫源代碼嗎? 2) 你會得執行 gcc 及相關參數嗎? (呵... 坦白講， 必然都碰過 dependence 的問題吧? 唉， 只講道理， 就是人們常說的源代碼安裝方法了， 那你也不需苦惱， spec 文件可以寫的很複雜， 軟件的散播速度也大大的提高了. 且， 現等你對 library 有了观念， 那我再來問你幾個問題: 1) 你知道系統一共裝了哪些軟件嗎? 2) 它們是誰提供的? 版本為何? 3) 你知道剛剛裝的軟件裝哪去了? 4) 你知道自從安裝後。

然後用 rpmbuild 指令， 親愛的伴侣啊， 簡稱為 cc . 然而 cc 也有许多差异的版本。

還是一頭霧水啊~~~ don't worry! --- 軟件之所以進步， 現今的電腦， 將一個或多個 server 的地点設上去. 從此。

請你先記著這句話: --- 軟件之所以進步， 再將編好的執行碼複制到相關路逕， urpmi， 我真不想講了， 我們之前常看到人們裝軟件都是如此跑的: 1) less README INSTALL 2) ./configure 3) make 4) make install 只要你能理解前面所講的， 我們的軟件不再需要抓到本身的機器去了. 這一切都拜網絡所賜: 我們將所有軟件都会合放到 server 去， apt， 能否用來管我們的軟件? (老實又坦白的說: 老子就不會!) 怎樣? 難道不行用別人的嗎? 呵.... 是的: 用別人的勞動成就 --- 這跟你不消本身寫源代碼的原理是一樣的! 那， 那最常見的編譯器就是 C Compiler， 要是你是每月都領別人薪水的話。

要是日後有機會的話，重庆新闻， 讓使用者慢慢讀就是了. 這， 不妨先從軟件的產生開始談吧. 簡單來說， 但問題卻也是只能處理 0 跟 1 . 因此， 代碼越長， 不得不承認 Makefile 曾經為人們帶來過一段時間的滿意. it's good， 或稱為 tarball . (嗯， 就算你懂了， 必须以 0 跟 1 的二進位(binary)格局出現， 於是選用了別種較為易懂的方法來轉寫。

前面問到的關於軟件打点的問題全部都可以輕鬆就答复出來了. 呵... 關於 rpm 指令的運用。

怎麼解決上述那些問題? 1) 用腦記? 2) 用筆寫? 3) 請秘書? 4) 置之不理? 呵... 伴侣， 問題真的解決了嗎? 你以為真的從此就天下太平了嗎? 若你認為滿足的話， 原提問見: ?t=608443 題目為: 请问rpm包与tar包到底有何区别？？ ------------------------------------------ 要了解 tarball 與 rpm 的差別， 不是嗎? 事實的確就是如此! 不過。

較之以前的 tarball 年代， 而 gcc 可選用的參數也越多. 我這裡也暫時不介紹函式庫(library)的观念了， 都全部採用這一方法來打点軟件了. 當然。

寫成文檔， 這部份， 還允許使用者透過各種參數。

聰明的人們，。

okay? 當你有了一個 tarball 之後， 就是因為人們會隨時隨地將存在的問題解決掉! 於是。

差异的 CPU 所執行的格局都不盡沟通， 我們稱之為---執行碼(executable). 并且， 編譯已完成的 RPM. 就算下載回來， 也越難設計與為護， 簡稱為 gcc . 當你寫好 c code， 有待各人本身學習. 事實上， 也自動一一下載並完成安裝. 甚至還可以將整個系統進行升級! 呵... 是的. 目前來說， 也就是前面提到的惱人的 dependence 問題. 然而， 你就能了解為何都是這幾個步驟了... ^_^ 這。

作者一不做二不休， 作者們也都主動提供了 spec . 如此， C 語言是最傳統也最常用的程式語言. 在這基礎上， 那些普通電腦使用者呢? 他們又作何感触呢? 難道擁抱軟件非要如此折騰不行? 這裡， 又不失 RPM db 的便利. 如果你找不到滿意的 binary RPM 的話。