diff --git a/Manual.md b/Manual.md index fc7efc3562d..2888807025d 100644 --- a/Manual.md +++ b/Manual.md @@ -31,6 +31,8 @@ packages for XBPS, the `Void Linux` native packaging system. * [32bit packages](#32bit_pkgs) * [Subpackages](#pkgs_sub) * [Development packages](#pkgs_development) + * [Data packages](#pkgs_data) + * [Documentation packages](#pkgs_documentation) * [Python packages](#pkgs_python) * [Go packages](#pkgs_go) * [Haskell packages](#pkgs_haskell) @@ -973,6 +975,42 @@ If a development package provides a `pkg-config` file, you should verify what dependencies the package needs for dynamic or static linking, and add the appropriate `development` packages as dependencies. +Development packages for the C and C++ languages usually `vmove` the +following subset of files from the main package: + + * Header files `usr/include` + * Static libraries `usr/lib/*.a` + * Shared library symbolic links `usr/lib/*.so` + * Cmake rules `usr/lib/cmake` + * Package config files `usr/lib/pkgconfig` + + +### Data packages + +Another common subpackage type is the `-data` subpackage. This subpackage +type used to split architecture independent, big(ger) or huge amounts +of data from a package's main and architecture dependent part. It is up +to you to decide, if a `-data` subpackage makes sense for your package. +This type is common for games (graphics, sound and music), part libraries (CAD) +or card material (maps). Data subpackages are almost always `noarch=yes`. +The main package must then have `depends="${pkgname}-data-${version}_${revision}"`, +possibly in addition to other, non-automatic depends. + + +### Documentation packages + +Packages intended for user interaction do not always unconditionally require +their documentation part. A user who does not want to e.g. develop +with Qt5 will not need to install the (huge) qt5-doc package. +An expert may not need it or opt to use an online version. + +In general a `-doc` package is useful, if the main package can be used both with +or without documentation and the size of the documentation isn't really small. +The base package and the `-devel` subpackage should be kept small so that when +building packages depending on a specific package there is no need to install large +amounts of documentation for no reason. Thus the size of the documentation part should +be your guidance to decide whether or not to split off a `-doc` subpackage. + ### Python packages