You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This guide will walk you through the process of building and testing packages locally on your system, regardless of whether they come from new package recipes or existing ones you are updating.
10
+
11
+
## Build the package
12
+
13
+
Once you have created or updated a package recipe, you will need to build it locally. If you are only updating one package, you can either keep your local repository disabled prior to building the package. If you prefer to keep it enabled, make sure there are no other packages indexed locally that could interfere with your new package build.
14
+
15
+
<Asidetype="note">
16
+
Please ensure you have followed the steps in the [Preparing for Packaging](/packaging/workflow/preparing-for-packaging/) guide to ensure you volatile repository is enabled.
17
+
</Aside>
18
+
19
+
20
+
The command to build the updated package is:
21
+
22
+
```bash
23
+
just build
24
+
```
25
+
26
+
If the package is successfully built, you will need to move it to your local repository. You can do this using the following command:
27
+
28
+
```bash
29
+
just mv-local
30
+
```
31
+
32
+
If you have not yet enabled the local repository, you do this with the following command:
33
+
34
+
```bash
35
+
sudo moss repo enablelocal
36
+
```
37
+
38
+
You will then need to sync the local repository using the command:
39
+
40
+
```bash
41
+
sudo moss sync -u
42
+
```
43
+
44
+
Note, if you already have an older version of the package installed, you will be asked if you want to update to the new local version you have just built. If you have not yet installed this package, you would install it as normal using the command:
45
+
46
+
```bash
47
+
sudo moss install "package name"
48
+
```
49
+
50
+
Once you have tested the package, you can make a submission for including the update in the repository.
51
+
52
+
<Asidetype="tip"title="How to submit pull requests">
53
+
To find guidance on how to submit a pull request (PR), you can refer to our [submit a pull request](/packaging/workflow/submitting-a-pr) page. s
This guide will walk you through the process using `ent`, a tool built by the AerynOS team to check for package updates. `ent` checks recipes against upstream sources to determine whether updates are available.
12
+
13
+
`ent` is not installed on your system by default. To install `ent` using `moss`, use the following command:
14
+
15
+
```bash
16
+
sudo moss install ent
17
+
```
18
+
### How `ent` works
19
+
20
+
`ent` scans the current directory and all subdirectories beneath it. It inspects each recipe `monitoring.yaml` file and compares the referenced `stone.yaml` recipe upstreams to determine whether newer versions are available.
21
+
22
+
Because `ent` operates relative to the directory in which it is executed, you can control the scope of the update check by choosing where to run the command within the recipes repository.
23
+
24
+
### Running update checks
25
+
26
+
To check for updates across all recipes, run the following command from the root of the recipes repository:
27
+
28
+
```bash
29
+
gotoaosrepo
30
+
ent check updates
31
+
```
32
+
33
+
You can also run this command from more specific locations:
34
+
35
+
***Repository root**
36
+
Checks all recipes in the repository.
37
+
38
+
***Letter directory (for example, `f/`)**
39
+
Checks only recipes whose names start with that letter.
40
+
41
+
***Specific recipe directory (for example, `f/firefox/`)**
42
+
Checks only that single recipe.
43
+
44
+
For example, running the command from `f/firefox/` will check only the Firefox recipe for available updates.
45
+
46
+
<Asidetype="note"title="What is ent?">
47
+
`ent` queries an upstream site for package release info *every time you run it*. Please be mindful of not running it gratuitously so as to remain a good ecosystem citizen.
0 commit comments