HyperWiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
en:manual:contrib:packaging_guidelines [2022/03/08 03:00]
i3_relativism ↷ Page moved from en:main:packaging_guidelines to en:project:packaging_guidelines 		en:manual:contrib:packaging_guidelines [2022/03/08 03:00]
i3_relativism ↷ Links adapted because of a move operation
Line 10: Line 10:
     * a) Software built and patched to be secure from global data surveillance revealed in the [[https://www.theguardian.com/world/interactive/2013/nov/01/snowden-nsa-files-surveillance-revelations-decoded|publication of Snowden's NSA documents]].     * a) Software built and patched to be secure from global data surveillance revealed in the [[https://www.theguardian.com/world/interactive/2013/nov/01/snowden-nsa-files-surveillance-revelations-decoded|publication of Snowden's NSA documents]].
     * b) Additional hardened packages which remove lower level protocols that may cause privacy leaks, metadata/fingerprinting, and vulnerabilities.     * b) Additional hardened packages which remove lower level protocols that may cause privacy leaks, metadata/fingerprinting, and vulnerabilities.
-  - **FHS**: All packages follow the [[en:main:FHS|Filesystem Hierarchy Standard (FHS)]] which defines the main directories and their contents in GNU/Linux and other Unix-like computer operating systems such as GNU/Hurd.  Therefore, all packages should be fixed using the required standard without exceptions.+  - **FHS**: All packages follow the [[en:project:fhs|Filesystem Hierarchy Standard (FHS)]] which defines the main directories and their contents in GNU/Linux and other Unix-like computer operating systems such as GNU/Hurd.  Therefore, all packages should be fixed using the required standard without exceptions.
   - **Free software projects**: If there is software that contain a stable version, then the upstream version should be blacklisted. There are examples such as:   - **Free software projects**: If there is software that contain a stable version, then the upstream version should be blacklisted. There are examples such as:
     * a) The long-term support (LTS) of Linux-libre kernel instead of the upstream one.     * a) The long-term support (LTS) of Linux-libre kernel instead of the upstream one.
Line 21: Line 21:
     * b) If a package is an important dependency for active projects and there is no a current replacement for it.     * b) If a package is an important dependency for active projects and there is no a current replacement for it.
     * c) If a package is a driver, firmware or hardware emulation and there is no a current replacement for it.     * c) If a package is a driver, firmware or hardware emulation and there is no a current replacement for it.
-  - **Snapshot versions**: Since Hyperbola is a long-term support (LTS) distribution; all packages are based on Arch snapshots and package versions based on Debian from the above-mentioned date announced in the Hyperbola mailing lists or main page, and designed to be supported for a longer than normal period until the [[en:main:releases|next stable release]]. Exceptions are considered:+  - **Snapshot versions**: Since Hyperbola is a long-term support (LTS) distribution; all packages are based on Arch snapshots and package versions based on Debian from the above-mentioned date announced in the Hyperbola mailing lists or main page, and designed to be supported for a longer than normal period until the [[en:project:releases|next stable release]]. Exceptions are considered:
     * a) Binutils and GCC should follow the same version used in HyperbolaBSD.     * a) Binutils and GCC should follow the same version used in HyperbolaBSD.
     * b) If a package version needs taking security parts from a newer version, but it is inefficient to be backported, a newer version could be considered as exception (see Backporting amendment for further details).     * b) If a package version needs taking security parts from a newer version, but it is inefficient to be backported, a newer version could be considered as exception (see Backporting amendment for further details).
-  - **Backporting**: Hyperbola uses the term backporting to describe a package built from a newer version, adjusted and adapted for usage on the [[en:main:releases|current stable release]]. It requires be repackaged with the appropriate package release "**backports$backportsreleasenumber**" (eg. pkgrel=1**.backports1**) until the [[en:main:releases|next stable release]]. Backporting is accepted in Hyperbola as exception, but under the following conditions: +  - **Backporting**: Hyperbola uses the term backporting to describe a package built from a newer version, adjusted and adapted for usage on the [[en:project:releases|current stable release]]. It requires be repackaged with the appropriate package release "**backports$backportsreleasenumber**" (eg. pkgrel=1**.backports1**) until the [[en:project:releases|next stable release]]. Backporting is accepted in Hyperbola as exception, but under the following conditions: 
-    * a) If the current package used on the [[en:main:releases|current stable release]] needs many modifications spread across multiple files of the code to solve some specific issue (eg. security issue) and it is inefficient to be fixed. +    * a) If the current package used on the [[en:project:releases|current stable release]] needs many modifications spread across multiple files of the code to solve some specific issue (eg. security issue) and it is inefficient to be fixed. 
-    * b) All newer version packages and its required newer version library and dependency packages should be repackaged with the appropriate package release too, since it will be rebuilt in a stable environment so that it will run without new libraries. This suffix is applied until the [[en:main:releases|next stable release]].+    * b) All newer version packages and its required newer version library and dependency packages should be repackaged with the appropriate package release too, since it will be rebuilt in a stable environment so that it will run without new libraries. This suffix is applied until the [[en:project:releases|next stable release]].
     * c) All newer version packages should follow the snapshot version and Debian's package version rules from Hyperbola Packaging Guidelines using its release date as a snapshot version and package versions based on Debian, it means Hyperbola **will not accept** recurrent drastic version changes as long as fixing is possible.     * c) All newer version packages should follow the snapshot version and Debian's package version rules from Hyperbola Packaging Guidelines using its release date as a snapshot version and package versions based on Debian, it means Hyperbola **will not accept** recurrent drastic version changes as long as fixing is possible.
   - **Package licenses**: All packages contain a license field that specifies the license(s) source that apply to the package using the commonly used licenses in /usr/share/licenses/common. It means, if a source is under a license which is available in /usr/share/licenses/common (eg. GPL-2), simply it should be referenced in the package license field (eg. license=('GPL-2')). If it is not the case, then it should be included in the package itself and set license=('custom:LicenseName'). The license file should be placed in /usr/share/licenses/$pkgname when building the package. If multiple licenses are applicable, the conditions are:   - **Package licenses**: All packages contain a license field that specifies the license(s) source that apply to the package using the commonly used licenses in /usr/share/licenses/common. It means, if a source is under a license which is available in /usr/share/licenses/common (eg. GPL-2), simply it should be referenced in the package license field (eg. license=('GPL-2')). If it is not the case, then it should be included in the package itself and set license=('custom:LicenseName'). The license file should be placed in /usr/share/licenses/$pkgname when building the package. If multiple licenses are applicable, the conditions are: