There are primary and auxiliary packages. A primary package of a software
is essential for running the software. Auxiliary packages are optional
addons.

Packages are named using one of the following two schemes:
	package--arch-version
	package-subpackage--arch-version

The shorter form is for primary packages, the longer form is for
auxiliary packages. The subpackage word is sort of free-form, but
the most common ones are:
	dev       lib packages: headers, the *.so symlink and other files required for building against a lib (pkgconfig too)
	dbgsym    lib packages: separated debug symbols for .so files, all in  /usr/lib/.debug/
	static    lib packages: .a files for static linking
	man       manual pages
	info      info pages
	doc       documentation
	lib       library for (TODO: xz has this but looks like a bad idea)
	util      auxiliary utilities (especially for libs)
	extra     rarely used optional parts parts that some users/systems may need
	old       rarely used, obsolete, old parts of the package (backward compatibility)


A "package name" is usually the package-subpackage (or just package for
primary packages). A full name includes the version. For example "bash"
and "bash-doc" are "package names", and the full name of "bash-doc" might
be "bash-doc--any-4.3.30".

Architectures:
	x86      80x86, 32 bits
	x86_64   80x86, 64 bits

Exceptions:

	- When a lib package does not have .so files only .a files, the main package
	  shall contain the .a files, there should be no static or dbgsym subpackage
	- When a lib package does not have .so and .a files, the main package is
	  empty, there should be no static or dbgsym subpackage
	- If a lib source package is split up into multiple binary packages it
	  is enough to have a single static, a single dbgsym and a single dev
	  subpackage (each including the relevant aux files for every subpackage)

Lib package numreic suffix
~~~~~~~~~~~~~~~~~~~~~~~~~~

For a lib there are really two versions. One is the source code version
(typically present in the tarball) and the other is the API version
(which ends up in the .so file as SOVERSION and is also the suffix of the
.so file). The numeric suffix in the package is derived from the API
version's major (first) number.

In an optimal world the major version of the source and the API match.
In practice this is not always the case. For example the source tarball
libXrender-0.9.10 installs /usr/lib/libXrender-1.3.0 so the API version
is 1.3.0 which means the package is called libxrender1.

The reason for package suffixing is allowing parallel installation of different
major versions of the same library (e.g. gtk2 and gtk4). The API version
suffixed so file names always differ so there is no collision there. If there
are aux files in the binary package (e.g. in /usr/lib/PACKAGE/) that directory
should also be major-version suffixed. The -dev packages may or may not be
installed for both versions in the same time, depending on upstream decisions.