[ 上一頁 ] [ 目錄 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ 下一頁 ]
現在我們假設有人提交了一個關於你的套裝軟體的bug報告,第#54321號,它描述了 一個你可以解決的問題。要為你的套裝軟體建立一個新的Debian修訂版,你需要:
當然,必需更正套裝軟體的來源程式碼中的問題。
在Debian changelog檔案中增加一個新的修訂版,比如透過命令“dch -i”或是是“dch -v <version>-<revision>”。然後 用你喜歡的純文字編輯器插入新的關於修改的註解資訊。
小技巧:如何才能方便地以希望的格式得到日期呢?使用“822-date”或 者是“date -R”。
在changelog的項目上包裝檔含一份對bug的簡短描述以及解決方法,並將它附加 在“Closes: #54321”之後。這樣,當你的套裝軟體被Debian文件庫接受的時候,這 個bug報告將會被文件維護軟體自動關閉。
重覆你在完整的rebuild, 第 6.1 節、檢查套裝軟體中的錯誤, 第 7 章和上傳套裝軟體, 第 8 章中所做的。不同的是這一次,原始的來源程式碼將不會被包裝檔括,因為它們並 沒有被修改並且已經存在於Debian的文件庫中了。
現在我們來考慮另外一種情況,一種稍微複雜一點的情況──一個上游的版本發佈 了,當然你會希望它能夠被打包裝檔。你需要做下面的事情:
下載新版本的來源程式碼,並將它的壓縮檔(比如“gentoo-0.9.13.tar.gz”)放到原 先的來源程式碼目錄樹的上層目錄中(比如~/gentoo/)。
進入舊的來源程式碼目錄,並且執行下面的命令:
uupdate -u gentoo-0.9.13.tar.gz
當然用你的新程式的文件名稱取代掉這裡的檔案名稱。uupdate(1)
將會修改這個壓縮檔的名字,還會試著將原先.diff.gz
檔案中的所有的修改套用到它上面,並且會更新新的debian/changelog
檔案。
更換到目錄“../gentoo-0.9.13
”中,它是新的套裝軟體來源碼目
錄樹,重覆你在完整的rebuild, 第
6.1 節、檢查套裝軟體中的錯誤, 第 7
章和上傳套裝軟體, 第 8 章中所做的。
注意如果你已經如watch.ex, 第 5.10
節所述建立了一個“debian/watch
”檔案,那麼你就可以透過執行uscan(1)
來自
動偵測新版本的來源程式碼並下載它們,然後執行uupdate
。
當為Debain檔案庫準備套裝軟體時,你必須仔細檢查最終的套裝軟體。下面是一個更加 實際的程序。
校驗上游修改
閱讀上游的changelog
、NEWS
及其它可能和新版本
一起發佈的文件。
用“diff -urN”比較新舊上游套裝軟體的差別,從而對修改的範圍有個概 略性的了解,哪些工作已經完成了(同時因此在哪裡可能會有新的bug),而且還要留心 觀察任何值得懷疑的東西。
把舊Debian套裝軟體升級為新版本。
解壓來源碼包裝檔,並修改來源碼樹的根目錄為<packagename>-<upstream_version>/
並“cd”到此目錄中。
複製父目錄中的來源碼包裝檔並將其更名為<packagename>_<upstream_version>.orig.tar.gz
。
對新的來源碼樹也進行與舊來源碼樹一樣的修改。可能的方法有:
“zcat /path/to/<packagename>_<old-version>.diff.gz | patch -p1”命令,
“uupdate
”命令
“svn merge”命令,如果你使用Subversion倉庫來管理來源碼,或是
直接將debian/
目錄從舊來源碼樹複製到新的來源碼樹中,如果它是
用dpatch
打包裝檔的。
保留舊的修改日誌項目(看上去不重要,但其實隨時會有意外...)
新套裝軟體的版本應該由上游版本號加上Debian修訂號-1構成,例 如“0.9.13-1”。
在debian/changele
檔案的頂部為此新版本加入修改日誌項目
──“新的上游版本”。例如“dch -v 0.9.13-1”.
簡要地說明新上游版本中修復的已報bug並在修改日誌中關閉這些bug。
簡要地說明維護者為修復已報bug對新上游版本所做的修改並且在修改 日誌中關閉這些bug。
如果補綴或是合併的程序並不順利,就要仔細地查出哪些地方有錯誤(在.rej
檔案中會留下線索。)多數情況下是因為你使用的補綴已經整合到上游版本
中,這樣就不再需要那補綴了。
向新版本的升級應當是安靜地且不會打擾到使用者(除非是發現舊的bug已經被修復 或是增加了新的功能,已有的使用者應當不會注意到升級。) [4]
如果你處於某種原因需要已經刪除的模板檔案,你可以在同一個已經“debian化”
的目錄中再次執行dh_make
,執行時加上-o選項。然後就可以
修改它了。
應當對已經存在的Debian修改進行重新評估;除非有什麼不得已的原因,都應當 刪除掉上游作者已經合併的(無論何種形式)並繼續保留上游作者並未合併的。
If any changes were made to the build system (hopefully you'd know from the
step 1 and update the debian/rules
and debian/control
build dependencies if necessary.
如debuild
命令, 第 6.3
節或pbuilder
包裝檔,
第 7.6 節所述建立新的套裝軟體。最好是使 用pbuilder
。
核對新套裝軟體是否建構正確。
在此檢查是否有已經修復但在Debian
Bug追蹤系統(BTS)
仍然為開啟狀態的bug。
檢查.changes檔案的內容以確認你把套裝軟體上傳到了正確的發行版中、已經關閉 的bug已經列出在“Closes:”網域中,而“Maintainer:Check”和“Changed-By:”網域可以匹配, 以及檔案已經用GPG簽署等等。
如果為修正任何內容而修改了套裝軟體,請傳回到第2步直到滿意。
如果你需要別人幫助才可以上傳,請一定要注意在建構套裝軟體的時候使用特殊的 選項(如“dpkg-buildpackage -sa -v ...”),同時請知會幫助你上傳的人以便他/她能夠正確建構套裝軟體。
如果你自己上傳,執行上傳套裝軟體, 第 8 章.
orig.tar.gz
檔案
如果你建構軟體時使用的來源碼樹只有debian/
目錄而沒有orig.tar.gz
檔案在其父目錄中,最後你將得到一個Debian專用來源碼包裝檔,
而沒有diff.gz
檔案。這種包裝檔裝方式應當只有對那些Debian專用的軟
件適用,這些套裝軟體在其它發行版中應當是完全沒有用處的。 [5]
要獲得由orig.tar.gz
和diff.gz
兩個檔案構成的
非Debian專用的來源碼包裝檔,你必須手動複製上游套裝軟體到父目錄中,並將其名稱改
為<packagename>_<upstream_version>.orig.tar.gz
,如首次“Debian化”, 第 2.4
節所述由dh_make
所做的那樣。
cvs-buildpackage
命令和similes你應當考慮使用一些來源碼關係系統來管理套裝軟體。有幾個腳本已經被訂製用於和 多數流行的系統一起工作。
CVS
cvs-buildpackage
Subversion
svn-buildpackage
Arch (tla)
tla-buildpackage
arch-buildpackage
這些命令也可以使對新版上游軟體的打包裝檔自動化。
當你建立了一個套裝軟體的新版本,你必需做下面的事情來確認所有的人都可以 安全的升級:
從原先的版本升級,
降級到原先的版本並刪除它,
安裝新的套裝軟體,
刪除它然後重新安裝它一遍,
徹底清楚它。
注意如果你以前的套裝軟體已經被發佈到Debian,人們會通常會更新到Debian最新 的發佈中的那個版本上,所以要記得測試從那個版本升級的情況。
[ 上一頁 ] [ 目錄 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ A ] [ 下一頁 ]
Debian新維護人員手冊
version 1.2.3, 2005年4月3日.joy-mg@debian.org
lilingv@gmail.com
ycheng@slat.org