1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
// file : bpkg/pkg-bindist.cli
// license : MIT; see accompanying LICENSE file
include <bpkg/configuration.cli>;
"\section=1"
"\name=bpkg-pkg-bindist"
"\summary=generate binary distribution package"
namespace bpkg
{
{
"<options> <vars> <out-dir> <pkg>",
"\h|SYNOPSIS|
\c{\b{bpkg pkg-bindist}|\b{bindist} [<options>] [<vars>] <out-dir> <pkg> [<pkg>...]}
\h|DESCRIPTION|
The \cb{pkg-bindist} command generates a binary distribution package for
the specified package. If additional packages are specified, then they
are bundled in the same distribution package. All the specified packages
must have been previously configured with \l{bpkg-pkg-build(1)} or
\l{bpkg-pkg-configure(1)}. The intermediate files and the resulting
binary package are created in the <out-dir> directory.
Underneath, this command roughly performs the following steps: First it
installs the specified packages similar to the \l{bpkg-pkg-install(1)}
command except that it may override the installation locations (via the
\cb{config.install.*} variables) to match the distribution's layout. Then
it generates any necessary distribution package metadata files based on
the information from the package \cb{manifest} files. Finally, it invokes
the distribution-specified command to produce the binary package. Unless
overrident with the \cb{--architecture} and \cb{--distribution} options,
the binary package is generated for the host architecture using the
host's standard system package manager. Additional command line variables
(<vars>, normally \cb{config.*}) can be passed to the build system during
the installation step.
The specified packages may have dependencies and the default behavior is
to not bundle them but rather to specify them as dependencies in the
corresponding distribution package metadata, if applicable. This default
behavior can be overridden with the \cb{--recursive} option (see the
option description for the available modes). Note, however, that
dependencies that are satisfied by system packages are always specified
as dependencies in the distribution package metadata.
"
}
// @@ Have section for each package manager with options?
class pkg_bindist_options: configuration_options
{
"\h|PKG-BINDIST OPTIONS|"
string --distribution
{
"<name>",
"Alternative system/distribution package manager to generate the binary
package for. The valid <name> values are \cb{debian} (Debian and
alike, such as Ubuntu, etc) and \cb{fedora} (Fedora and alike,
such as RHEL, CentOS, etc). Note that some package managers may
only be supported when running on certain host operating systems."
}
string --architecture
{
"<name>",
"Alternative architecture to generate the binary package for. The
valid <name> values are system/distribution package manager-specific.
If unspecified, the host architecture is used."
}
string --recursive
{
"<mode>",
"Bundle dependencies of the specified packages. The <mode> value can be
either \cb{auto}, in which case only the required files from each
dependency package are bundled, or \cb{full}, in which case all the
files are bundled. Specifically, in the \cb{auto} mode any required
files, for example, shared libraries, are pulled implicitly by the
\cb{install} build system operation, for example, as part of
installing an executable from one of the specified packages. In
contrast, in the \cb{full} mode, each dependency package is
installed explicitly and completely, as if they were specified
as additional package on the command line. See also the \cb{--private}
option."
}
bool --private
{
"Enable the private installation subdirectory functionality using the
binary package name as the private subdirectory. This is primarily
useful when bundling dependencies, such as shared libraries, of an
executable that is being installed into a shared location, such as
\cb{/usr/}. See the \cb{config.install.private} configuration variable
documentation in the build system manual for details. This option
only makes sense together with \cb{--recursive}."
}
bool --wipe-out
{
"Wipe the output directory (\ci{out-dir}) clean before using it to
generate the binary package."
}
bool --keep-out
{
"Keep intermediate files in the output directory (\ci{out-dir}) that
were used to generate the binary package. This is primarily useful
for troubleshooting."
}
};
"
\h|DEFAULT OPTIONS FILES|
See \l{bpkg-default-options-files(1)} for an overview of the default
options files. For the \cb{pkg-bindist} command the search start
directory is the configuration directory. The following options files are
searched for in each directory and, if found, loaded in the order listed:
\
bpkg.options
bpkg-pkg-bindist.options
\
The following \cb{pkg-bindist} command options cannot be specified in the
default options files:
\
--directory|-d
\
"
}
|