moritzruth/void-packages
1
0
Fork 0
Code Releases Activity Actions 2

Manual.md, CONTRIBUTING.md: move quality requirements to CONTRIBUTING

Browse source 
rename to Package Requirements
This commit is contained in:
classabbyamp 2022-08-12 13:06:20 -04:00 • committed by classabbyamp
parent 241b0b85ce
commit c9871df9f2
2 changed files with 23 additions and 33 deletions
Download patch file Download diff file Expand all files Collapse all files

33
Manual.md
View file

@ -6,7 +6,6 @@ packages for XBPS, the `Void Linux` native packaging system.
*Table of Contents*
* [Introduction](#Introduction)
* [Quality Requirements](#quality_requirements)
* [Package build phases](#buildphase)
* [Package naming conventions](#namingconventions)
* [Libraries](#libs)
@ -124,38 +123,6 @@ If everything went fine after running
a binary package named `foo-1.0_1.<arch>.xbps` will be generated in the local repository
`hostdir/binpkgs`.
<a id="quality_requirements"></a>
### Quality Requirements
To be included in the Void repository, software must meet at least one
of the following requirements. Exceptions to the list are possible,
and might be accepted, but are extremely unlikely. If you believe you have an
exception, start a PR and make an argument for why that particular piece of
software, while not meeting any of the following requirements, is a good candidate for
the Void packages system.
1. System: The software should be installed system-wide, not per-user.
1. Compiled: The software needs to be compiled before being used, even if it is
software that is not needed by the whole system.
1. Required: Another package either within the repository or pending inclusion
requires the package.
In particular, new themes are highly unlikely to be accepted. Simple shell
scripts are unlikely to be accepted unless they provide considerable value to a
broad user base. New fonts may be accepted if they provide value beyond
aesthetics (e.g. they contain glyphs for a script missing in already packaged
fonts).
Browser forks, including those based on Chromium and Firefox, are generally not
accepted. Such forks require heavy patching, maintenance and hours of build time.
Software need to be used in version announced by authors as ready to use by
the general public - usually called releases. Betas, arbitrary VCS revisions,
templates using tip of development branch taken at build time and releases
created by the package maintainer won't be accepted.
<a id="buildphase"></a>
### Package build phases