leetNightshade
/
help-center-docs
Archived
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix some line breakage. Drop fairly useless Guide page pending some sexy Help Center changes.

This commit is contained in:
Joshua Strobl 2017-07-22 15:07:06 +03:00
parent 3e58b0ac89
commit 65bf80b59a
No known key found for this signature in database
GPG Key ID: 3F6FD9A6B13E584D
3 changed files with 2 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
packaging/guide/en.md
View File

@ -1,34 +0,0 @@
+++
title = "Packaging Guide"
+++
# Packaging Guide
This guide is aimed at those wishing to either maintain existing packages, or contribute packaging, to the Solus repositories.
We assume you already have a working knowledge of Linux based systems, and are already comfortable with compiling software from source.
## Supported targets
You may either build natively on your Solus installation using the `ypkg` tool directly, or or on supported distributions in a chroot environment via the `solbuild` tool. Please note that in order to use `solbuild` from
other distributions, your kernel must support `overlayfs`, which must be enabled and loaded.
## Overview
Solus uses the `eopkg` package manager, which creates `.eopkg` binary packages. Internally an eopkg file contains a `metadata.xml` file, describing the package in full, along with file contents, plus an `install.tar.xz`
In order to directly build a `.eopkg`, the developer must complete a `package.yml` file, to describe the build steps involved and the metadata. However, as this is more of a machine format, we opted for a meta-build
format to ensure packaging was both simple and rules based.
To this end, we use `ypkg`. This uses a YAML format file, which simply contains relevant package information, and the build steps. The tool will decide upon the relevant subpackages upon build completion, and then
pass the packaging step to `eopkg` at the end.
Macros are made available to the developer to ensure the package uses the relevant distribution options, and that the resulting package is compliant with the specific distribution rules.
The key difference between `ypkg` and traditional package building systems, is that the developer has very little choice about the naming of packages and subpackages. Automatic rules are applied to ensure the correct
level of splitting occurs, freeing the developer from hours of arduous packaging reducing the entire process to what is essentially a highly organised document with embedded shell scripts.
## Getting Started
Firstly, we recommend reading about [Package.yml](/articles/packaging/package.yml/en), our format based on the YAML specification for packages.
Following the creation of your package.yml file, you'll need to [build the package](/articles/packaging/building-a-package/en), followed by [submitting a patch for the package](/articles/packaging/submitting-a-package/en).

3
packaging/package-inclusion-policy/en.md
View File

@ -8,8 +8,7 @@ This policy sets forth the criteria for a package to be accepted for inclusion i
- 2-Distro Waiver:
- If the software appears in Debian and/or Ubuntu, Fedora, 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.
- 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 Waiver.
- 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)

3
packaging/request-a-package/en.md
View File

@ -5,8 +5,7 @@ title = "Requesting a Package"
Packages are how users install Software in Solus, however if we are missing one you can let us know using our Task Tracker.
**Please look to see if a bug has been filed for the software or library you require**. If there isn't an existing request, you can use the template below for requesting packages to be added to the Solus
Package Repository or Third Party Repository.
**Please look to see if a bug has been filed for the software or library you require**. If there isn't an existing request, you can use the template below for requesting packages to be added to the Solus Package Repository or Third Party Repository.
Please provide as much of the following information as possible: