Budowanie Pakietow Arch

From ArchWiki

Jump to: navigation, search


i18n
English
Deutsch
Español
Русский
简体中文
繁體中文
Français
Polski

Contents

Standardy

Kiedy buduje się pakiety Arch Linux, zawsze powinno przestrzegać się poniższych zasad zwłaszcza jeśli chcesz dołączyć Twój pakiet do dystrybucji Arch Linux. Warto przeczytać także strony man: PKGBUILD i makepkg.

Prototyp PKGBUILD

# Contributor: Twoje Dane <TwojEmail at domena kropka pl> (zabezpiecz e mail przed spamem)

pkgname=NAZWA
pkgver=WERSJA
pkgrel=1
pkgdesc=""
arch=('i686' 'x86_64')
url="http://ADRES/"
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #wygeneruj przez 'makepkg -g'

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr
  make || return 1
  make DESTDIR=$pkgdir install || return 1
}

Ogólnie przyjęte zasady

  • Pakiey nigdy nie powinny być instalowane do /usr/local
  • Jeśli to możliwe, używaj "|| return 1" w ważnych funkcjach służących do budowania, np.
    patch -Np1 -i ../patchfile.patch || return 1
    make || return 1
    make DESTDIR=$pkgdir install || return 1
    	
  • Nie twórz nowych zmiennych w skryptach w pliku PKGBUILD chyba, że jest to wymagane do zbudowania pakietu. Takie zmienne mogą być w konflikcie ze zmiennymi używanymi przez makepkg. Jeżeli zmienna jest koniecznie potrzebna, poprzedź jej nazwą znakiem podkreślenia (_) np.:
    _mojazmienna=

    The AUR cannot detect the use of custom variables and so cannot use them in substitutions. This can most often be seen in the source array e.g.

    http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2

    Such a situation defeats the effective functionality of the AUR.

  • Unikaj stosowania /usr/libexec/ do wszystkiego. Zamiast użyj /usr/lib/${pkgname}/.
  • Pole packager może być skonfigurowane dla każdego pakietu poprzez zmianę odpowiedniej opcji w pliku /etc/makepkg.conf lub poprzez eksport zmiennej środowiskowej PACKAGER przed zbudowanie pakietu makepkg:
    # export PACKAGER="Ktos Tam@your.email"
  • Wszystkie ważne informacje powinny być drukowane na ekran podczas instalacji przy użyciu pliku .install file. Na przykład jeśli pakiet wymaga dodatkowych czynności poinstalacyjnych odpowiednie wskazówki powinny zostać dołączone.
  • Żadne dodatkowe zależności niewymagane do poprawnego działania programu nie powinny być dołączane. Informacje o takich zależności można umieszczać w sekcji optdepends:
    optdepends=('cups: printing support'
                'sane: scanners support'
                'libgphoto2: digital cameras support'
                'alsa-lib: sound support'
                'giflib: GIF images support'
                'libjpeg: JPEG images support'
                'libpng: PNG images support')
    

    Powyższy przykład wzięty jest z pakietu wine z repozytorium extra. Informacje z optdepends automatycznie drukowane są podczas instalacji/aktualizacji od wersji 3.2.1 pacmana, więc już nie powinno się umieszczać tych informacji w pliku .install.

  • Podczas uzupełniania opisu pakietu nie zawiera się w nim jego nazwy. Na przykład: "Nedit jest edytorem tekstu dla X11", upraszczamy do "Edytor tekstu dla X11". Ponadto opis nie powinien być dłuższy niż ~80 znaków.
  • Staraj się utrzymaćdługość lini w PKGBUILD poniżej ~100 znaków.
  • Jeśli to możliwe, usuń puste linie z PKGBUILD (provides, replaces, itp.)
  • Powszechną praktyką jestutrzymywanie kolejności pól w PKGBUILD jak w powyższym przykładzie. Nie jest to jednak obowiązkowe. Jedynym wymogiem jest poprawna składnia skryptów basha.

Nazwy pakietów

  • Nazwy pakietów powinny składać się tylko ze znaków alfanumerycznych; wszystkie litery powinny być małe.
  • Wersja pakietu powinna być zgodna z wersją autora programu. Wersje mogą zawierać litery (np., nmap 2.54BETA32). Numer wersji nie powinien zawierać łączników (myślników, podkreśleń). Tylko litery, cyfry i kropki.
  • Wydania pakietu odnoszą się tylko do Arch Linuksa. Pozwalają na odróżnienie nowszych i starszych wydań tego samego pakietu. Kiedy wydana zostaje nowa wersja pakietu licznik wydań wraca do 1. Po umieszczeniu poprawek w pakiecie może on być wydany ponownie z podwyższonym o 1 licznikiem wydania. Licznik wydań podlega tym samym zasadom co numer wersji.

Katalogi

  • Pliki konfiguracyjne powinny być umieszczane w /etc. W przypadku większej ilości plików konfiguracyjnych dopuszczalne jest użycie podkatalogu w celu utrzymania porządku. Możesz używać /etc/{pkgname}/, gdzie {pkgname} jest nazwą pakietu (lub odpowiedniej innej nazwy, np.: apache używa /etc/httpd/).
  • Pliki pakietu powinny być zgodne z poniższymi ogólnymi wytycznymi:
  • /etc

    Systemowe pliki konfiguracyjne

    /usr/bin Skompilowane programy
    /usr/sbin Programy systemowe
    /usr/lib Biblioteki
    /usr/include Pliki nagłówkowe
    /usr/lib/{pkg} Moduły, plug-iny, itp.
    /usr/share/doc/{pkg} Dokumentacja programu
    /usr/share/info Pliki systemowe GNU Info
    /usr/share/man Strony man
    /usr/share/{pkg} Dane programu
    /var/lib/{pkg} Dane zmienne
    /etc/{pkg} Pliki konfiguracyjne pakietu {pkg}
    /opt/{pkg}

    Duże, niezależne programy, np. Java

  • Pakiety nie powinny korzystać z następujących katalogów:
    • /dev
    • /home
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp

Czynności wykonywane przez Makepkg

Używając makepkg do budowanaia pakietów following automatically:

  1. Checks if package dependencies and makedepends are installed
  2. Downloads source files from servers
  3. Checks the integrity of source files
  4. Unpacks source files
  5. Does any necessary patching
  6. Builds the software and installs it in a fake root
  7. Strips symbols from binaries
  8. Strips debugging symbols from libraries
  9. Compresses manual and, or info pages
  10. Generates the package meta file which is included with each package
  11. Compresses the fake root into the package file
  12. Stores the package file in the configured destination directory (cwd by default)

Architectures

The arch array should contain 'i686' and/or 'x86_64' depending on which architectures it can be built on. You can also use 'any' for architecture independent packages, but the official repositories of Arch (core, extra, community) do not support it yet, thus if you want the package to enter the main repositories, then do not use 'any' at the moment. You can certainly use 'any' for your personal repositories.

Licenses

The license array is being implemented little by little in the official repos, and it should be used in your packages as well. You can use it as follows:

  • A licenses package has been created in [core] that stores common licenses in /usr/share/licenses/common ie. /usr/share/licenses/common/GPL. If a package is licensed under one of these licenses, the licenses variable will be set to the directory name e.g. license=('GPL')
  • If the appropriate license is not included in the official licenses package, several things must be done:
    1. The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/COPYING.
    2. If the source tarball does NOT contain the license details and the license is only displayed on a website for example, then you need to copy the license to a file and include it. Remember to call it something appropriate too.
    3. Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.
  • Once a licenses is used in two or more packages in an official repo, including [community], it becomes common
  • The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkg. For the sake of the license variable, it's treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it's a custom license, because each one has its own copyright line. Each MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.
  • Some packages may not be covered by a single license. In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license"). For the majority of packages these licenses apply in different cases, as opposed to applying at the same time. When pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.
  • The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:
    • (L)GPL - (L)GPLv2 or any later version
    • (L)GPL2 - (L)GPL2 only
    • (L)GPL3 - (L)GPL3 or any later version

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 difference. 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. Remember to disguise your email to protect against spam:
    # Contributor: Your Name <address at domain dot com>
  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.

    You can easily build a tarball containing all the required files by using makepkg --source. This makes a tarball named $pkgname-$pkgver-$pkgrel.src.tar.gz, which you can then upload to the AUR.

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

Additional Guidelines

Be sure to read the above guidelines first - important points are listed on this page that will not be repeated in the following guideline pages. These specific guidelines are intended as an addition to the standards listed on this page.

CVS/SVN Packages

Please see the Arch CVS & SVN PKGBUILD guidelines

Gnome Packages

Please see the Gnome package guidelines

Haskell Packages

Please see the Haskell package guidelines

Java Packages

Please see the Java Package Guidelines

Lisp Packages

Please see the Lisp Package Guidelines

Perl Packages

Please see the Perl Package Guidelines

Python Packages

Please see the Python Package Guidelines

Ruby Gem Packages

Please see the Ruby Gem Package Guidelines

Wine Packages

Please see the Arch wine PKGBUILD guidelines

Kernel Module Packages

Please see the Kernel Module Package Guidelines

Personal tools