Budowanie Pakietow Arch
From ArchWiki
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 środowiskowejPACKAGER
przed zbudowanie pakietumakepkg
:# 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:
-
Pakiety nie powinny korzystać z następujących katalogów:
- /dev
- /home
- /media
- /mnt
- /proc
- /root
- /selinux
- /sys
- /tmp
- /var/tmp
/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 |
Czynności wykonywane przez Makepkg
Używając makepkg do budowanaia pakietów following automatically:
- Checks if package dependencies and makedepends are installed
- Downloads source files from servers
- Checks the integrity of source files
- Unpacks source files
- Does any necessary patching
- Builds the software and installs it in a fake root
- Strips symbols from binaries
- Strips debugging symbols from libraries
- Compresses manual and, or info pages
- Generates the package meta file which is included with each package
- Compresses the fake root into the package file
- 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:
- The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/COPYING.
- 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.
- 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:
- 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.
-
To ensure the security of pkgs submitted to the AUR please ensure that you have correctly filled the
md5sum
field. Themd5sum
's can be generated using themakepkg -g
command. -
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>
-
Verify the package dependencies (eg, run
ldd
on dynamic executables, check tools required by scripts, etc). The TU team strongly recommend the use of thenamcap
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 thenamcap
package withpacman
. Remembernamcap
can be used to check both pkg.tar.gz files and PKGBUILDs - 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.
- 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.
-
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