help-center-docs/packaging/package-inclusion-policy/en.md

---
title: Package Inclusion Policy
---
# Package Inclusion Policy

This policy sets forth the criteria for a package to be accepted for inclusion into the Solus repositories.

- 2-Distro Rule:
 - If the software appears in Debian and/or Ubuntu, and openSUSE, in the **currently active, core** repositories, the maintainer is permitted to waive some entry requirements (This does not apply to software license, 
 legality or known-insecure software. Additionally this cannot be used to bypass the server rules.). PPAs, OBS projects outside of the **openSUSE**: namespace, or Arch Linux, do **NOT** add any weight to a request.
- Software Age:
 - DOA (dead-on-arrival) packages are generally rejected from Solus. However, they may be included at the discretion of the project, if they provide unique functionality. In addition, this software **MUST** comply with the 
 2-Distro Rule.
 - Projects with no tags/tarballs which lack traction, may be frozen until a suitable release is made. Tagging releases is an indicator for good release engineering practices.
 - Typically, we prefer **stable** tagged releases. However, this may be waived if:
  - The software has significant traction (i.e. prerelease)
  - A bug fix only exists beyond the latest stable release for a git source
- Value Add:
 - A web wrapper which **adds value**, such as Discord, with the global push-to-talk shortcut, is eligible for inclusion.
 - A web page wrapper, that adds **no further value** other than “convenient desktop shortcut” or “tray icon”, is **NOT** eligible for inclusion. Web browsers already support desktop notifications.
 - If the newly requested package offers no functionality above that of an alternative already in the repositories, it will very likely be rejected. “It’s pretty” is never a sufficient reason.
 - Likewise, when a new package offers a better alternative to an **existing** package, we should look to replace the old one with the new one, to ensure the repository is always deduplicating.
- Explicitly Redistributable:
 - Software under a free software or open source software license, or license text which explicitly states that it is **permissible** to redistribute the software.
 - For anything that cannot be redistributed by Solus, there is the possibility for them to be provided as a Flatpak, for Third Party repository inclusion. These items should then fetch only at installation time, and not 
 contain non distributable components.
 - Solus supports both VCS (currently only git, this will expand) and traditional software sources (such as tarballs) for packages, equally.
 - Unless **absolutely unavoidable**, the sources for a package should be source, and not **binary, prebuilt** sources. Exceptions may be made in rare cases, such as stage1 bootstrap for a compiler, or requires custom 
 components otherwise impossible to provide in Solus (patched libraries, etc.)
- Server software:
 - Mail servers such as Postfix, Dovecot, etc, are **NOT** eligible for inclusion. Solus does not provide a server operating system.
 - Web servers and database daemons **ARE** eligible for inclusion, as they facilitate web developers to work locally.
 - Anything outside of these may be catered to by the usage of Docker, or other container technology. Thus, container technology must be supported by Solus to support access to ancillary cases.
- Stack Complexity:
 - Certain requests may tick all the boxes, but introduce a level of complexity or require a level of engagement not possible to balance for the packaging team. Under certain situations, a request will be frozen until it has 
 a dedicated maintainer.
 - This extends to requests for full desktop environments. However, this does not extend to minor components like drop-in window managers or panels separate of a dependent stack (i.e. Awesome WM, tint2, etc.)
-												Add Package Inclusion Policy.

											
										
										
											2017-02-20 13:34:06 +00:00
+								---
 								title: Package Inclusion Policy
 								---
 								# Package Inclusion Policy
 								This policy sets forth the criteria for a package to be accepted for inclusion into the Solus repositories.
 								- 2-Distro Rule:
 								 - If the software appears in Debian and/or Ubuntu, and openSUSE, in the **currently active, core** repositories, the maintainer is permitted to waive some entry requirements (This does not apply to software license,
 								 legality or known-insecure software. Additionally this cannot be used to bypass the server rules.). PPAs, OBS projects outside of the **openSUSE**: namespace, or Arch Linux, do **NOT** add any weight to a request.
 								- Software Age:
 								 - DOA (dead-on-arrival) packages are generally rejected from Solus. However, they may be included at the discretion of the project, if they provide unique functionality. In addition, this software **MUST** comply with the
 -Distro Rule.
 								 - Projects with no tags/tarballs which lack traction, may be frozen until a suitable release is made. Tagging releases is an indicator for good release engineering practices.
 								 - Typically, we prefer **stable** tagged releases. However, this may be waived if:
 								  - The software has significant traction (i.e. prerelease)
 								  - A bug fix only exists beyond the latest stable release for a git source
 								- Value Add:
 								 - A web wrapper which **adds value**, such as Discord, with the global push-to-talk shortcut, is eligible for inclusion.
 								 - A web page wrapper, that adds **no further value** other than “convenient desktop shortcut” or “tray icon”, is **NOT** eligible for inclusion. Web browsers already support desktop notifications.
 								 - If the newly requested package offers no functionality above that of an alternative already in the repositories, it will very likely be rejected. “It’s pretty” is never a sufficient reason.
 								 - Likewise, when a new package offers a better alternative to an **existing** package, we should look to replace the old one with the new one, to ensure the repository is always deduplicating.
 								- Explicitly Redistributable:
 								 - Software under a free software or open source software license, or license text which explicitly states that it is **permissible** to redistribute the software.
 								 - For anything that cannot be redistributed by Solus, there is the possibility for them to be provided as a Flatpak, for Third Party repository inclusion. These items should then fetch only at installation time, and not
 								 contain non distributable components.
 								 - Solus supports both VCS (currently only git, this will expand) and traditional software sources (such as tarballs) for packages, equally.
 								 - Unless **absolutely unavoidable**, the sources for a package should be source, and not **binary, prebuilt** sources. Exceptions may be made in rare cases, such as stage1 bootstrap for a compiler, or requires custom
 								 components otherwise impossible to provide in Solus (patched libraries, etc.)
 								- Server software:
 								 - Mail servers such as Postfix, Dovecot, etc, are **NOT** eligible for inclusion. Solus does not provide a server operating system.
 								 - Web servers and database daemons **ARE** eligible for inclusion, as they facilitate web developers to work locally.
 								 - Anything outside of these may be catered to by the usage of Docker, or other container technology. Thus, container technology must be supported by Solus to support access to ancillary cases.
 								- Stack Complexity:
 								 - Certain requests may tick all the boxes, but introduce a level of complexity or require a level of engagement not possible to balance for the packaging team. Under certain situations, a request will be frozen until it has
 								 a dedicated maintainer.
 								 - This extends to requests for full desktop environments. However, this does not extend to minor components like drop-in window managers or panels separate of a dependent stack (i.e. Awesome WM, tint2, etc.)