Arch linux package format

Arch package guidelines

When building packages for Arch Linux, adhere to the package guidelines below, especially if the intention is to contribute a new package to Arch Linux. You should also see the PKGBUILD(5) and makepkg(8) manpages.

PKGBUILD prototype

# Maintainer: Your Name pkgname=NAME pkgver=VERSION pkgrel=1 pkgdesc="" arch=() url="" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= changelog= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #autofill using updpkgsums build() < cd "$pkgname-$pkgver" ./configure --prefix=/usr make >package() < cd "$pkgname-$pkgver" make DESTDIR="$pkgdir/" install >

Other prototypes are found in /usr/share/pacman/ from the pacman package.

Package etiquette

• Packages should never be installed to /usr/local/
• Do not introduce new variables or functions into PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables and functions used in makepkg itself.
• If a new variable or a new function is absolutely required, prefix its name with an underscore ( _ ), e.g.

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')

• When creating a package description for a package, do not include the package name in a self-referencing way. For example, «Nedit is a text editor for X11» could be simplified to «A text editor for X11». Also try to keep the descriptions to ~80 characters or less.
• Try to keep the line length in the PKGBUILD below ~100 characters.
• Where possible, remove empty lines from the PKGBUILD ( provides , replaces , etc.)
• It is common practice to preserve the order of the PKGBUILD fields as shown above. However, this is not mandatory, as the only requirement in this context is correct bash syntax.
• Quote variables which may contain spaces, such as «$pkgdir» and «$srcdir» .
• To ensure the integrity of packages, make sure that the integrity variables contain correct values. These can be updated using the updpkgsums(8) tool.

Package naming

• Package names can contain only alphanumeric characters and any of @ , . , _ , + , — . Names are not allowed to start with hyphens or dots. All letters should be lowercase.
• Package names should not be suffixed with the upstream major release version number (e.g. we do not want libfoo2 if upstream calls it libfoo v2.3.4) in case the library and its dependencies are expected to be able to keep using the most recent library version with each respective upstream release. However, for some software or dependencies, this can not be assumed. In the past this has been especially true for widget toolkits such as GTK and Qt. Software that depends on such toolkits can usually not be trivially ported to a new major version. As such, in cases where software can not trivially keep rolling alongside its dependencies, package names should carry the major version suffix (e.g. gtk2, gtk3, qt4, qt5). For cases where most dependencies can keep rolling along the newest release but some cannot (for instance closed source that needs libpng12 or similar), a deprecated version of that package might be called libfoo1 while the current version is just libfoo.

Package versioning

• Package versions (i.e. PKGBUILD#pkgver) should be the same as the version released by the author. Versions can include letters if need be (eg, nmap’s version is 2.54BETA32 ). Version tags may not include hyphens! Letters, numbers, and periods only.
• Package releases (i.e. PKGBUILD#pkgrel) are specific to Arch Linux packages. These allow users to differentiate between newer and older package builds. When a new package version is first released, the release count starts at 1. Then as fixes and optimizations are made, the package will be re-released to the Arch Linux public and the release number will increment. When a new version comes out, the release count resets to 1. Package release tags follow the same naming restrictions as version tags.

Package dependencies

• Do not rely on transitive dependencies in any of the PKGBUILD#Dependencies, as they might break, if one of the dependencies is updated.
• List all direct library dependencies. To identify them find-libdeps(1) (part of devtools ) can be used.

Package relations

• Do not add $pkgname to PKGBUILD#provides, as it is always implicitly provided by the package.
• List all external shared libraries of a package in PKGBUILD#provides (e.g. ‘libsomething.so’ ). To identify them find-libprovides(1) (part of devtools ) can be used.

Package sources

• HTTPS sources ( https:// for tarballs, git+https:// for git sources) should be used wherever possible
• Sources should be verified using PGP signatures wherever possible (this might entail building from a git tag instead of a source tarball, if upstream signs commits and tags but not the tarballs)
• When building from a git tag, use its object hash obtained from git rev-parse instead of the tag name:

_tag=1234567890123456789012345678901234567890 # git rev-parse «v$pkgver» source=(git+https://$url.git?signed#tag=$_tag) pkgver()

• Do not diminish the security or validity of a package (e.g. by removing a checksum check or by removing PGP signature verification), because an upstream release is broken or suddenly lacks a certain feature (e.g. PGP signature missing for a new release)
• Sources have to be unique in srcdir (this might require renaming them when downloading, e.g. «$.tar.gz::https://$.tld/download/$.tar.gz» )
• Avoid using specific mirrors (e.g. on sourceforge) to download, as they might become unavailable

Working with upstream

It is considered best-practice to work closely with upstream wherever possible. This entails reporting problems about building and testing a package.

• Report problems to upstream right away.
• Upstream patches wherever possible.
• Add comments with links to relevant (upstream) bug tracker tickets in the PKGBUILD (this is particularly important, as it ensures, that other packagers can understand changes and work with a package as well).

It is recommended to track upstream with tools such as nvchecker or urlwatch to be informed about new stable releases.

Directories

• Configuration files should be placed in the /etc directory. If there is more than one configuration file, it is customary to use a subdirectory in order to keep the /etc area as clean as possible. Use /etc/pkg where pkg is the name of the package (or a suitable alternative, eg, apache uses /etc/httpd/ ).
• Package files should follow these general directory guidelines:

• Packages should not contain any of the following directories:
  • /bin
  • /sbin
  • /dev
  • /home
  • /srv
  • /media
  • /mnt
  • /proc
  • /root
  • /selinux
  • /sys
  • /tmp
  • /var/tmp
  • /run

  Makepkg duties

  When makepkg is used to build a package, it does the 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 (i.e. the current working directory by default)

  Architectures

  The arch array should contain ‘x86_64’ if the compiled package is architecture-specific. Otherwise, use ‘any’ for architecture independent packages.

  Licenses

  Reproducible builds

  Arch is working on making all packages reproducible. A packager can check if a package is reproducible with makerepropkg from devtools or repro from archlinux-repro .

  $ makerepropkg $pkgname-1-1-any.pkg.tar.zst

  $ repro -f $pkgname-1-1-any.pkg.tar.zst

  If the timestamp is required at build-time, use the environment variable SOURCE_DATE_EPOCH . The format is documented upstream.

  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.

  Packages submitted to the AUR must additionally comply with AUR submission guidelines.

  Источник

  Arch Linux

  I have been playing around with pacman in the freebsd operating system. My goal is just to install a package into the freebsd system with pacman (no dependencies for now). The idea is to compile the software with the freebsd ports system, make a freebsd package and convert that to a pacman package to install it. I could not find information of the package format of pacman. However, both packages format look very similar, so I think the conversion should be straight forward.

  Do you know of any documentation of the pacman package format? Are there any tools that can help me with this?

  #2 2009-03-22 05:16:08

  FrozenFox Member From: College Station, TX Registered: 2008-03-23 Posts: 422 Website

  Re: Arch Linux package format

  #3 2009-03-22 05:54:48

  Re: Arch Linux package format

  PKGBUILDs and the format in which pacman stores metadata are different. PKGBUILDs are for makepkg consumption. When creating the package, makepkg creates a sort of ini file — .PKGINFO. This file has all the metadata about the package. This file, along with all the package files, and an .INSTALL file, if an install scriptlet is used, are compressed into a pacman package. I’d suggest you simply download an archlinux package, extract it somewhere, and have a look at .PKGINFO. It’s a very simple format to parse,

  I’m not sure how easy it would be to actually track the files from the ports install. I assume ports has a way of listing all files of a package.

  #4 2009-03-22 09:37:56

  Re: Arch Linux package format

  AFAIK, they are normal tarballs, with all the appropriate files ready to be extracted to / (ie, /usr/bin/rsync)

  tar xvzf packagename.pkg.tar.gz

  There is also the .PKGINFO file with specific info for pacman. Extracting a package, and examining the PKGINFO file should give you some good stuff.

  #5 2009-03-23 03:00:20

  Re: Arch Linux package format

  Thank you guys. After some thinking, I was just wondering if it is probably easier to convert freebsd ports to PKGBUILD and use the makepkg tool to compile the applications. But this probably deserves another post.

  #6 2009-03-24 00:46:37

  Re: Arch Linux package format

  I think it’d be more work to write an auto-converter (and deal with bad PKGBUILDs it makes) than to just manually write PKGBUILDs — they’re beyond simple

  #7 2009-03-24 01:13:22

  Re: Arch Linux package format

  makepkg should work fine on BSD although you might need to get the git version. There have been several patches to improve compatibility with BSD and Mac OSX,

  #8 2009-03-24 05:21:28

  Re: Arch Linux package format

  makepkg should work fine on BSD although you might need to get the git version. There have been several patches to improve compatibility with BSD and Mac OSX,

  I can’t really speak for BSD compatibility, but makepkg (stable) works fine on Mac OS X, beyond the lack of fakeroot support (on the OS). I believe repo-add has only recently been patched up to work, so you’d need the git version for that (and possibly other complementary tools).

  Either way it would be good to try it and report any incompatibilities on the mailing list/bug tracker .

  Last edited by Xilon (2009-03-24 05:21:39)

  #9 2009-04-03 18:11:18

  Re: Arch Linux package format

  I think it’d be more work to write an auto-converter (and deal with bad PKGBUILDs it makes) than to just manually write PKGBUILDs — they’re beyond simple

  I agree. Additionally many ports stop and want you fill out options which would further complicate.

  I’m intrigued by the idea of having a pacman based BSD system, though in the long run it would warrant it’s own BSD distro (ArchBSD if you will), and would not be that useful on top of Free/Net/Open BSD.

  I would envision ArchBSD based on an ArchBSD ABS tree, and not on ports. (Although ports would be a primary reference for how to build packages).

  The options for ports brings the same problems that Gentoo useflags have into the mix. How does one deal will variations of a package, and are those variations part of the dependency information? Just food for thought.

  Источник