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 		Previous revision
en:manual:contrib:packaging_guidelines [2018/10/13 06:03]
emulatorman 		en:manual:contrib:packaging_guidelines [2024/05/26 12:49] (current)
throgh
Line 1: Line 1:
 ====== Hyperbola Packaging Guidelines ====== ====== Hyperbola Packaging Guidelines ======
  
-The **Hyperbola Packaging Guidelines** is the commitment that we, the Hyperbola Project, make to the Free Software Community in general and our users in particular. It is because of this that our packaging guidelines will always follow the philosophy of freedom, privacy, stability and security.+The **Hyperbola Packaging Guidelines** is the commitment that we, the Hyperbola Project, make to the Free Software Community in general and our users in particular. It is because of this that our packaging guidelines will always follow the philosophy of __freedom, privacy, stability and security__.
  
   - **Freedom**: All packages follow the [[https://www.gnu.org/distros/free-system-distribution-guidelines.html|GNU Free System Distribution Guidelines]]. They do not include or recommend non-free software or documentation and do not provide any type of support for the installation or execution of non-free software. This includes:   - **Freedom**: All packages follow the [[https://www.gnu.org/distros/free-system-distribution-guidelines.html|GNU Free System Distribution Guidelines]]. They do not include or recommend non-free software or documentation and do not provide any type of support for the installation or execution of non-free software. This includes:
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 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: +  - **Package versions**: Since Hyperbola is a long-term support (LTS) system; all packages are based on the package versions Debian is using foremost in the current stable or old-stable and designed to be supported for a longer than normal period until the [[en:project:releases|next stable release]]. Exceptions are considered: 
-    * a) If a package version in the snapshot is 1.1.0, and there is a bugfix in 1.1.1, it could be upgraded because it is a revision, not a strong upgrade or a drastic version change. +    * a) Binutils and GCC should follow the same version used in HyperbolaBSD. 
-    * b) If a package version in the snapshot is 1.1.0.a, and there is a bugfix in 1.1.0.b, it could be upgraded because it is a revision, not a strong upgrade or a drastic version change. +    * 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). 
-    * c) If a package version in the snapshot is 1.1.0-beta, and there is a final version in 1.1.0, it could be upgraded. +  - **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: 
-    * d) If a package version in the snapshot is 1.1.0-beta without plans for a final version, and there is a 2.0.0-rc, it could be upgraded as exception. +    * 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. 
-    * e) If a package version in the snapshot is 1.1.0 and depends on abandonware project (eg. OpenRC 0.25.x depends on SysVinit), and there is a 1.2.0 with a replacement, it could be upgraded as bugfix version. (eg. SysVinit is replaced with openrc-init in OpenRC 0.28.x). +    * 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]]. 
-    * f) If a package version in the snapshot is a long-term support (LTS) project, all minor versions of a release series are accepted as exception such as ESR 52 series in the libre version of Iceweasel (eg. 52.x.x). +    * c) All newer version packages should follow the package version rules from Hyperbola Packaging Guidelines, it means Hyperbola **will not accept** recurrent drastic version changes as long as fixing is possible. 
-    * g) 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). +  - **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 release**: All packages contain a release number specific in the pkgrel for package maintainers to make updates to the package's configure flags inside PKGBUILD. This is typically set to 1 for each new stable upstream software release and incremented for intermediate PKGBUILD updates, however if a package comes from Arch or AUR with modifications made for Hyperbola, then it should set to "$archreleasenumber**.hyperbola$hyperbolareleasenumber**" (eg. pkgrel=1**.hyperbola1**). Exceptions are considered: +    * a) If an upstream source provides the preference to choose a license, add only that license in the package license field. The chosen license must be compatible with the linked library dependencies used by the package. (eg. if the chosen license for ffmpeg is the version 3 of LGPL, then the configure parameter `--enable-version3` must be added in ffmpeg's PKGBUILD to activate this licensing option and use the LGPL-3 compatible libraries).
-    * a) If a package was not modified from official Arch or AUR package(s). +
-    * b) If a package was built from a libre replacement project (eg. Linux-libre kernel) or another libre project not included in Arch or AUR. +
-  - **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**" for official Arch, AUR or Hyperbola packages (eg. pkgrel=1**.backports1**) and Arch or AUR packages modified by Hyperbola (eg. pkgrel=1.hyperbola1**.backports1**) until the [[en:main: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. +
-    * 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]]. +
-    * c) All newer version packages should follow the snapshot version rules from Hyperbola Packaging Guidelines using its release date as a snapshot version, 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. GPL2), simply it should be referenced in the package license field (eg. license=('GPL2')). 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: +
-    * a) If an upstream source provides the preference to choose a license, add only that license in the package license field. The chosen license must be compatible with the linked library dependencies used by the package. (eg. if the chosen license for ffmpeg is the version 3 of LGPL, then the configure parameter `--enable-version3` must be added in ffmpeg's PKGBUILD to activate this licensing option and use the LGPL3-compatible libraries)+
     * b) If an upstream source contains files with many different licenses, add only the primary ones in the package license field.     * b) If an upstream source contains files with many different licenses, add only the primary ones in the package license field.
     * c) All chosen primary and compatible license files from the upstream source should be placed in /usr/share/licenses/$pkgname.     * c) All chosen primary and compatible license files from the upstream source should be placed in /usr/share/licenses/$pkgname.
Line 50: Line 42:
     * d) If there is an official tarball, however tarballs from the official Debian repositories contain bugfixes. In this case, the official tarballs from Debian should be used by default. (eg. Mutt+NeoMutt bugfixes)     * d) If there is an official tarball, however tarballs from the official Debian repositories contain bugfixes. In this case, the official tarballs from Debian should be used by default. (eg. Mutt+NeoMutt bugfixes)
     * e) If there is an official tarball, however it requires download git submodules to be built from the source. In this case, tarballs from the official Debian repositories is the alternative option.     * e) If there is an official tarball, however it requires download git submodules to be built from the source. In this case, tarballs from the official Debian repositories is the alternative option.
-    * f) If there are no available tarballs. In this case, it should be used in a specific tag or branch from a version control system (VCS) and repackaged with the appropriate suffix (eg. **-bzr** for Bazaar, **-git** for Git, **-hg** for Mercurial and **-svn** for Subversion) until a final version is available. +    * f) If there are no available tarballs anywhere: In this case the software is not to be used finally. 
-    * g) If there is not support for GNU/Linux in tarballs, tags or branches. In this case, a master branch from a version control system (VCS) could be used temporarily and repackaged with the appropriate suffix (eg. **-bzr** for Bazaar, **-git** for Git, **-hg** for Mercurial and **-svn** for Subversion) until a final version with GNU/Linux support is available. +  - **SHA-512**: All packages should use SHA-512 cryptographic hash functions only. Other cryptographic hash functions such as MD5 and SHA-1 should not be used because they are severely compromised. Exceptions are considered:
-  - **SHA512 or WHIRLPOOL**: All packages should use SHA512 or WHIRLPOOL cryptographic hash functions only. Other cryptographic hash functions such as MD5 and SHA1 should not be used because they are severely compromised. Exceptions are considered:+
     * a) If the package is using a version control system (VCS) because it does not contain GNU/Linux support or/and tarballs.     * a) If the package is using a version control system (VCS) because it does not contain GNU/Linux support or/and tarballs.
   - **GPG**: All packages should use signature verification. Exceptions are considered:   - **GPG**: All packages should use signature verification. Exceptions are considered:
     * a) If tarballs do not contain signatures.     * a) If tarballs do not contain signatures.
-  - **Anti-obfuscation**: obfuscation is the deliberate act of creating obfuscated code, i.e. source or machine code that is difficult for humans to understand. All obfuscated code will be rejected without exceptions.+    * b) If the corresponding gpg-key is no longer valid. 
 +  - **Anti-obfuscation**: obfuscation is the deliberate act of creating obfuscated code, i.e. source or machine code that is difficult for humans to understand. All obfuscated code will be **rejected** without exceptions. 
 +  - **No GNU/Linux-only software**: As Hyperbola is oriented on UNIX we do not support software only for GNU/Linux. As long as there is no need for a driver or any other framework running Hyperbola GNU/Linux-libre as transition-base towards HyperbolaBSD we will not add the software.