Nonfree applications package guidelines

From ArchWiki
Revision as of 21:58, 18 March 2012 by AlexanderR (Talk | contribs) (fix template)

Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: tell about extracting icons from exe files, encrypting archives, symlinking etc. (Discuss in Talk:Nonfree applications package guidelines#)
Template:Article summary start

Template:Article summary text Template:Article summary end

Template:Package Guidelines

For many applications (most of which are Windows ones) there are neither sources nor tarballs available. Many of such applications can not be freely distributed because of license restrictions and/or lack of legal ways to obtain installer for no fee. Such software obviously can not be included into the official repositories but due to nature of AUR it is still possible to privately build packages for it, manageable with pacman.

Note: All information here is package-agnostic, for information specific to the most typical nonfree software see Wine PKGBUILD guidelines.

Rationale

There are multiple reasons for packaging even non-packageable software:

  • Simplification of installation/removal process
This is applicable even to simplest apps, which consist of single script to be installed into /usr/bin. Instead of issuing:
$ chmod +x filename
# cp filename /usr/bin/
you can type just
# makepkg -i
Most non-free applications are obviously much more complicated and burden of downloading archive/installer from homepage (often full of advertising), unpacking/decrypting it, hand-writing stereotypic launcher scripts and doing other similar tasks can be effectively lightened by well-written packaging script.
  • Utilizing pacman capabilities
Ability to track state and perform automatic update of any installed piece of software, determine ownership of every single file and store compressed packages in well-organized cache is what makes GNU/Linux distributions so powerful.
  • Sharing code and knowledge
It is really simple to apply tweaks, fix bugs and seek/provide help in single public place like AUR in comparison to submitting patches to proprietary developer who already ceased support or asking vague questions on general purpose forums.

Common rules

Avoid nonfree software when possible

Yes, better leave this guide and spend some time searching (or maybe even creating) alternative to application you wanted to package because

  1. packaging ill software is mess which is generally against The Arch Way
  2. it is clever to support FOSS developers who generally care about users more

Use open source variants where possible

Many commercial games (some are listed in this Wiki) have open source engines, lots of old games can be played with emulators such as ScummVM. Usage of open source engines together with original game assets gives users access to bug fixes and eliminate lots of issues caused by binary packages.

Keep it simple

If packaging of of some program requires more effort and hacks than buying & using original version - do the simplest thing, it is Arch!

Package Naming

Before choosing name on your own search in AUR for existing version of software you want to package. Try to use established naming conversion (e.g. do not create something like gish-hbAUR when there are already aquaria-hib-hgAUR, penumbra-overture-hibAUR and uplink-hibAUR). Use suffix -bin always unless you are sure there will never be source-based package – it's creator would have to ask you (or in worst case TUs) to orphan existing package for him and you both will end up with PKGBUILDs cluttered with additional replases and conflicts.

File placement

Again analyze existing packages (if present) and decide whether or not you want to conflict with them. Do not place things under /opt unless you want to use some ugly hacks like giving ownership root:games to package directory (for users in group games to be able to run game writing files in it's own folder).

Missing files

For most commercial games there is no way to (legally) download game files, which is preferable way to get them for normal packages. Even when it is possible to download files after providing password (like with all Humble Indie Bundle games) asking user for this password and downloading somewhere in build function is not recommended for variety of reasons (for example user can have no Internet access but have all files downloaded and stored locally). Following options should be considered:

  • There is only one way to obtain files
  • Software is distributed in archive/installer
add required file to sources array:
sources=(... "originalname::file://originalname")
This way link to file in AUR web interface will look different from names of files, included in source tarball.
Add following comment on package page:
Need archive/installer is required for work.
and explain in details in PKGBUILD source.
  • Software is distributed on compact-disk
add installer script and .install file to package contents like in package tsukihime-enAUR.
  • There are several ways to obtain files

Copying files from disk / downloading from Net / getting from archive during build phase may look like good idea but it is not recommended because it limits user's possibilities and makes package installation interactive (which is generally discouraged and just annoying). Again good installer script and .install file can do work.

Few examples of various strategies of obtaining files required for package:

  • worldofgooAUR – dependency on user-provided file
  • umineko-enAUR – combining files from freely available patch and user-provided compact-disk
  • worldofgoo-demoAUR – autonomic fetching installer during build phase
  • ut2004-anthologyAUR – searching for disk via mountpoints