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

Manual.md: reword section on automatically detected depends

Browse source 
Co-authored-by: Mohammed Anas <triallax@tutanota.com>
This commit is contained in:
Piotr Wójcik 2023-06-26 20:13:46 +02:00 • committed by Chocimier
parent 7f54831c8e
commit 68462fe0ac
1 changed files with 13 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

25
Manual.md
View file

@ -789,24 +789,25 @@ should be listed in `checkdepends` and will be installed as if they were part of
<a id="deps_runtime"></a> <a id="deps_runtime"></a>
Lastly, a package may require certain dependencies at runtime, without which it Lastly, a package may require certain dependencies at runtime, without which it
is unusable. These dependencies, when they aren't detected automatically by is unusable. These dependencies, when they aren't detected automatically by
XBPS, should be listed in `depends`. This is mostly relevant for Perl and Python XBPS, should be listed in `depends`.
modules and other programs that use `dlopen(3)` instead of dynamically linking.
Dependencies for ELF objects are detected automatically by `xbps-src`, hence runtime Libraries linked by ELF objects are detected automatically by `xbps-src`, hence they
dependencies must not be specified in templates via `$depends` with the following exceptions: must not be specified in templates via `depends`. This variable should list:
- executables called as separate processes.
- ELF objects using dlopen(3). - ELF objects using dlopen(3).
- non ELF objects, i.e perl/python/ruby/etc modules. - non-object code, e.g. C headers, perl/python/ruby/etc modules.
- Overriding the minimal version specified in the `shlibs` file. - data files.
- overriding the minimal version specified in the `common/shlibs` file.
The runtime dependencies for ELF objects are detected by checking which SONAMEs The runtime dependencies for ELF objects are detected by checking which SONAMEs
they require and then the SONAMEs are mapped to a binary package name with a minimal they require and then the SONAMEs are mapped to a binary package name with a minimal
required version. The `shlibs` file in the `void-packages/common` directory required version. The `common/shlibs` file
sets up the `<SONAME> <pkgname>>=<version>` mappings. sets up the `<SONAME> <pkgname>>=<version>` mappings.
For example the `foo-1.0_1` package provides the `libfoo.so.1` SONAME and For example the `foo-1.0_1` package provides the `libfoo.so.1` SONAME and
software requiring this library will link to `libfoo`; the resulting binary software requiring this library will link to `libfoo.so.1`; the resulting binary
package will have a run-time dependency to `foo>=1.0_1` package as specified in package will have a run-time dependency on `foo>=1.0_1` package as specified in
`common/shlibs`: `common/shlibs`:
``` ```
@ -820,13 +821,13 @@ libfoo.so.1 foo-1.0_1
- The second field specified the package name and minimal version required. - The second field specified the package name and minimal version required.
- A third optional field (usually set to `ignore`) can be used to skip checks in soname bumps. - A third optional field (usually set to `ignore`) can be used to skip checks in soname bumps.
Dependencies declared via `${depends}` are not installed to the master directory, rather are Dependencies declared via `depends` are not installed to the master directory, rather they are
only checked if they exist as binary packages, and are built automatically by `xbps-src` if only checked if they exist as binary packages, and are built automatically by `xbps-src` if
the specified version is not in the local repository. the specified version is not in the local repository.
As a special case, `virtual` dependencies may be specified as runtime dependencies in the As a special case, `virtual` dependencies may be specified as runtime dependencies in the
`${depends}` template variable. Several different packages can provide common functionality by `depends` template variable. Several different packages can provide common functionality by
declaring a virtual name and version in the `${provides}` template variable (e.g., declaring a virtual name and version in the `provides` template variable (e.g.
`provides="vpkg-0.1_1"`). Packages that rely on the common functionality without concern for the `provides="vpkg-0.1_1"`). Packages that rely on the common functionality without concern for the
specific provider can declare a dependency on the virtual package name with the prefix `virtual?` specific provider can declare a dependency on the virtual package name with the prefix `virtual?`
(e.g., `depends="virtual?vpkg-0.1_1"`). When a package is built by `xbps-src`, providers for any (e.g., `depends="virtual?vpkg-0.1_1"`). When a package is built by `xbps-src`, providers for any