Fix up some linking.
This commit is contained in:
parent
222fc4219e
commit
c88daece55
|
@ -26,5 +26,5 @@ The Markdown files in this repository are licensed under the Creative Commons By
|
|||
|
||||
### Media Assets
|
||||
|
||||
- Solus logo copyright and licensing information is provided on our [Brand Guidelines page](https://solus-project.com/brand-guidelines).
|
||||
- Solus logo copyright and licensing information is provided on our [Brand Guidelines page](/brand-guidelines).
|
||||
- Non-logo assets are licensed under Creative Commons By-NC-SA 4.0 License. For the full text, view LICENSE-MD.txt. Solus Project is considered the sole rights holder of these works.
|
|
@ -1,7 +1,7 @@
|
|||
# Wireless Chipsets Compatibility
|
||||
|
||||
The following wireless chipsets have been tested and/or suggested to function correctly by our users. This list should not suggest that **only*- such devices listed below are compatible with Solus, as there may be devices not listed below that are in
|
||||
fact compatible. If you have a device compatible with Solus not listed on this page, please get a hold of `JoshStrobl` [via IRC](/help-center/contributing/getting-involved/).
|
||||
fact compatible.
|
||||
|
||||
## Atheros
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ The first step to installing Solus is acquiring the correct media. The Solus Pro
|
|||
|
||||
## Getting the ISO
|
||||
|
||||
You can download a Solus ISO by going to our [Download page](https://solus-project.com/download).
|
||||
You can download a Solus ISO by going to our [Download page](/download).
|
||||
|
||||
---
|
||||
|
||||
|
|
|
@ -6,20 +6,26 @@ We assume you already have a working knowledge of Linux based systems, and are a
|
|||
|
||||
### 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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).
|
|
@ -73,7 +73,7 @@ Never submit a package without having first tested it, and ensuring it builds wi
|
|||
|
||||
### Generating a Package.yml
|
||||
|
||||
Making a package.yml file is not necessarily a manual process. In fact, [once you have common setup](https://wiki.solus-project.com/Building_packages#Setting_up_common), you already have a script capable of generating a package.yml file based
|
||||
Making a package.yml file is not necessarily a manual process. In fact, [once you have common setup](/articles/packaging/building-a-package/en), you already have a script capable of generating a package.yml file based
|
||||
on the source archive URL.
|
||||
|
||||
You can generate a package.yml by using `common/Scripts/yauto.py URL_TO_ARCHIVE`. We recommend creation an alias in your `.bashrc` or `.zshrc`, so you can access it wherever you are. For example:
|
||||
|
|
|
@ -21,6 +21,6 @@ Pushing changes is not possible unless you have maintainer access. The same is a
|
|||
|
||||
To request maintainer rights for a repository, it is expected that some level of contribution/maintenance has already happened by way of testing/patching, and there is reasonable trust demonstrated to "hand the keys" over to a repository.
|
||||
|
||||
Currently, the request mechanism [contact Ikey on IRC](/help-center/contributing/getting-involved/). It is far easier to grant access to active community members than those unknown to the project.
|
||||
Currently, the request mechanism [contact Ikey on IRC](/articles/contributing/getting-involved/en). It is far easier to grant access to active community members than those unknown to the project.
|
||||
|
||||
Finally, note that the management reserve the right to revoke access at any time, in order to preserve project safety and integrity.
|
|
@ -8,4 +8,4 @@ You can use Docker as a provider for Vagrant. You can install Docker via the `do
|
|||
|
||||
## VirtualBox
|
||||
|
||||
You can use VirtualBox as a provider by following the "Solus As Host" instructions [here](https://wiki.solus-project.com/VirtualBox).
|
||||
You can use VirtualBox as a provider by following the "Solus As Host" instructions [here](/articles/software/virtualbox/en).
|
Reference in New Issue