Difference between revisions of "Arch packaging standards (正體中文)"

From ArchWiki
Jump to: navigation, search
(No difference)

Revision as of 03:38, 1 January 2010

Template:I18n links start Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n links end

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Arch packaging standards (正體中文)#)

套件規範

套件命名規則

  • 套件名稱只能以數字跟字母組成,且全部都需為小寫。
  • 版本號(version)要跟原作者釋出的相同。版本號可以由字母、數字跟 '.' 組成,但不能有 '-'。
  • 釋出版號(release)是 Arch Linux 特有的,這用來讓使用者識別新舊版本。當一個新的套件釋出,釋出版號(release) 是從 1 開始算,當之後有作修正或是最佳化的版本釋出的話,釋出版號(release) 則累加 1。當原作者釋出新版的話,則釋出版號(release)重設為 1。釋出版號(release)與版本號(version)遵守相同的命名規則。
  • 例如:目前最新的 nmap 版本為 4.20-1,4.20即為版本號(version),'-1'的部份表示釋出版號(release)為1。

目錄

  • 設定檔要被放在 /etc 目錄內。如果有超過一個以上的設定檔,應該在 /etc 內建立子目錄來放置,以保持 /etc 的整潔。使用如 /etc/{套件名}/ 目錄來放置對應套件的設定檔,或是選用一個具有代表意義的亦可。
  • 套件本身的檔案要遵守以下的規範:
    • /etc: 系統必備的設定檔
    • /usr/bin: 應用程式執行檔
    • /usr/sbin: 系統執行檔
    • /usr/lib: 函式庫
    • /usr/include: 標頭檔
    • /usr/lib/{pkg}: 套件 {pkg} 的模組、外掛等等
    • /usr/man: Manpages
    • /usr/share/{pkg}: 套件 {pkg} 的資料
    • /etc/{pkg}: 套件 {pkg} 的設定檔
    • /opt: Large self-contained packages such as KDE, Mozilla, etc.

makepkg 的責任

當你使用 makepkg 來製作套件時,它會自動為你做下列動作:

  1. 檢查套件的相依套件是否已被安裝
  2. 從伺服器上下載原始碼
  3. 解開原始碼
  4. 使用需要的補丁
  5. 編譯此軟體,並安裝在假的根目錄
  6. 移除 /usr/doc, /usr/info, /usr/share/doc, /usr/share/info 這些目錄中此軟體安裝的資料
  7. 去除掉二進位執行檔中的符號(symbols)
  8. 去除掉函式庫中的除錯用符號
  9. 產生每個套件中都會有的 meta file
  10. 將假的根目錄壓縮起來成為套件檔
  11. 將套件存在設定好的目的資料夾(預設是目前目錄)

Submitting Packages to the AUR

Note the following before submitting any packages to the AUR:

  1. The submitted PKGBUILDs MUST NOT build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that differency. eg. A GNU screen PKGBUILD submitted containing the sidebar patch, could be named screen-sidebar etc. Additionally the provides('screen') PKGBUILD array should be used in order to avoid conflicts with the official package.
  2. To ensure the security of pkgs submitted to the AUR please ensure that you have correctly filled the md5sum field. The md5sum's can be generated using the makepkg -g command.
  3. Please add a comment line to the top of your PKGBUILD file that follows this format:
    # Contributor: Your Name <your.email>
  4. Verify the package dependencies (eg, run ldd on dynamic executables, check tools required by scripts, etc). The TU team strongly recommend the use of the namcap utility, written by Jason Chu (jason@archlinux.org), to analyze the sanity of your package. namcap will tell you about bad permissions, missing dependencies, un-needed dependencies, and other common mistakes. You can install the namcap package with pacman. Remember namcap can be used to check both pkg.tar.gz files and PKGBUILDs
  5. Dependencies are the most common packaging error. Namcap can help detect them, but it is not always correct. Verify dependencies by looking at source documentation and the program website.
  6. Don't use replaces in your PKGBUILD unless you want to rename your package, for example when Ethereal became Wireshark. If you just provide an alternate version of an already existing package, use conflicts (and provides if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching replaces anywhere in its repositories; conflicts on the other hand is only evaluated when actually installing the package, which is pretty much always the desired behavior because you don't push your package down other people's throat this way.
  7. All files uploaded to the AUR should be contained in a compressed tar file containing a directory with the PKGBUILD and additional build files (patches, install, ...) in it.
    foo/PKGBUILD
    foo/foo.install
    foo/foo_bar.diff
    foo/foo.rc.conf

    The archive name should contain the name of the package e.g. foo.tar.gz

    The tarball should not contain the binary tarball created by makepkg, nor should it contain the filelist

套件規矩

許可

提交套件

其他指導方針

CVS/SVN 套件

Java 套件