24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
-
+
-
+
-
+
-
+
|
Which obviously does require the plugin manager to be somewhat more involved. You'll often get away just implementing a `>=` check. Most other version expression gimmicks are likely overkill for simple applicatiion-level features.
## System/language dependencies
While a `TYPE:name` entry can reference other scopes (instead of application-local plugins)
| `bin:imagemagick` | for binaries |
| `bin:imagemagick` | verify a binary exists |
| `python:lxml` | for language modules |
| `sys:amd64` | for the architecture. |
| `sys:amd64` | e.g. the architecture. |
| `deb:anacron` | as hint for the system package manager. |
| `api:archnemesis` | see [api](wiki/api) ]
| `api:archnemesis` | see [api](wiki/api) |
This is quite informal still. There's also less practical value to implement theese complex dependency lookups, or these exact ones. This is just the advised syntax.
This is quite informal still. There's seldomly practical value to implement such complex dependency lookups, or these exact ones. This is just the advised syntax.
## Related fields
Depending on complexity other fields might be used alongside:
* `# provides:`
* `# conflicts:`
* `# suggests:`
|