doc/manual.txt: update for xbps-src>=90.
This commit is contained in:
Juan RP
parent
6185affd57
commit
dee0d7d400
|
|
@ -29,8 +29,8 @@ A simple `template` example is as follows:
|
|||
|
||||
pkgname="foo"
|
||||
version="1.0"
|
||||
revision="1"
|
||||
build_style="gnu-configure"
|
||||
revision=1
|
||||
build_style=gnu-configure
|
||||
short_desc="A short description max 72 chars"
|
||||
maintainer="name <email>"
|
||||
license="GPL-3"
|
||||
|
|
@ -38,16 +38,20 @@ homepage="http://www.foo.org"
|
|||
distfiles="http://www.foo.org/foo-${version}.tar.gz"
|
||||
checksum="fea0a94d4b605894f3e2d5572e3f96e4413bcad3a085aae7367c2cf07908b2ff"
|
||||
|
||||
## optional
|
||||
foo-devel_package() {
|
||||
short_desc+=" - development files"
|
||||
depends="..."
|
||||
pkg_install() {
|
||||
vmove usr/include
|
||||
}
|
||||
}
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
|
||||
There are two main `sections` in a template: the `source section` and the
|
||||
`package section`. The `source section` contains definitions to download, build
|
||||
and install the package files to a `fake destdir`. The `package section`
|
||||
contains the definitions to how the resulting binary packages are generated.
|
||||
|
||||
A template always requires at least a `source section` and a `package section`;
|
||||
multiple `package sections` can be defined to generate `multiple binary packages`.
|
||||
The template file contains definitions to download, build and install the
|
||||
package files to a `fake destdir`, and after this a binary package can be
|
||||
generated with the definitions specified on it.
|
||||
|
||||
Don't worry if anything is not clear as it should be. The reserved `variables`
|
||||
and `functions` will be explained later. This `template` file should be created
|
||||
|
|
@ -56,7 +60,7 @@ If everything went fine after running `xbps-src build-pkg` a binary package
|
|||
called `foo-1.0_1.<arch>.xbps` will be generated in the local repository.
|
||||
|
||||
Additional binary packages (those defined in `_package() blocks` need a
|
||||
symlink to the `main` package, like this:
|
||||
symlink to the `main` package), like this:
|
||||
|
||||
----------------------------------
|
||||
|
||||
|
|
@ -154,7 +158,7 @@ rather than additional binary package names.
|
|||
|
||||
*PKGDESTDIR*::
|
||||
Full path to the fake destdir used by the `pkg_install()` function in the
|
||||
`package section`, set to `${XBPS_MASTERDIR}/destdir/pkg-${pkgname}-${version}`.
|
||||
`package section`, set to `${XBPS_MASTERDIR}/destdir/${pkgname}-${version}`.
|
||||
|
||||
*XBPS_MACHINE*::
|
||||
The machine architecture as returned by `uname -m`.
|
||||
|
|
@ -168,6 +172,8 @@ rather than additional binary package names.
|
|||
*XBPS_TARGET_MACHINE*::
|
||||
The target machine architecture when cross compiling a package.
|
||||
|
||||
*XBPS_FETCH_CMD*::
|
||||
The utility to fetch files from `ftp`, `http` of `https` servers.
|
||||
|
||||
Source section
|
||||
--------------
|
||||
|
|
@ -322,6 +328,22 @@ Example `skip_extraction="foo-${version}.tar.gz"`.
|
|||
even if `XBPS_DEBUG_PKGS` is disabled in `xbps-src.conf` or in the
|
||||
`command line arguments`.
|
||||
|
||||
*conf_files*::
|
||||
A list of configuration files the binary package owns; this expects full
|
||||
paths, and multiple entries can be separated by blanks, i.e:
|
||||
`conf_files="/etc/foo.conf /etc/foo2.conf"`.
|
||||
|
||||
*noarch*::
|
||||
If set, the binary package is not architecture specific and can be shared
|
||||
by all supported architectures.
|
||||
|
||||
*nonfree*::
|
||||
If set, the binary package will be put into the *non free* repository.
|
||||
|
||||
*nostrip*::
|
||||
If set, the ELF binaries with debugging symbols won't be stripped. By
|
||||
default all binaries are stripped.
|
||||
|
||||
build style scripts
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
The `build_style` variable specifies the build method to build and install a
|
||||
|
|
@ -502,36 +524,6 @@ The build options can also be shown for binary packages via `xbps-query(8)`:
|
|||
$ xbps-query -R --property=build-options foo
|
||||
--------------------------------------------
|
||||
|
||||
Package section
|
||||
---------------
|
||||
Mandatory functions
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
A `package section` needs at least one mandatory function matching the
|
||||
`$pkgname` of the `source section`: `<pkgname>_package()`. Multiple binary
|
||||
packages with the same template can be created by adding additional
|
||||
`<pkg>_package()` functions.
|
||||
|
||||
Those `<pkg>_package()` functions are run in alphabetical order, with the
|
||||
exception of the `<pkgname>_package()` function, which is always the last one.
|
||||
|
||||
Optional variables
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
*conf_files*::
|
||||
A list of configuration files the binary package owns; this expects full
|
||||
paths, and multiple entries can be separated by blanks, i.e:
|
||||
`conf_files="/etc/foo.conf /etc/foo2.conf"`.
|
||||
|
||||
*noarch*::
|
||||
If set, the binary package is not architecture specific and can be shared
|
||||
by all supported architectures.
|
||||
|
||||
*nonfree*::
|
||||
If set, the binary package will be put into the *non free* repository.
|
||||
|
||||
*nostrip*::
|
||||
If set, the ELF binaries with debugging symbols won't be stripped. By
|
||||
default all binaries are stripped.
|
||||
|
||||
Run-time dependencies
|
||||
---------------------
|
||||
Dependencies for ELF executables or shared libraries are detected
|
||||
|
|
|
|||
Loading…
Reference in New Issue