summaryrefslogtreecommitdiff
path: root/doc/guide/files/pkginstall.xml
blob: b08f7c9d4d7a028d773d7a5957bee4ae43ae87b2 (plain)
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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
<!-- $NetBSD: pkginstall.xml,v 1.17 2012/05/16 16:46:43 wiz Exp $ -->

<chapter id="pkginstall"> <?dbhtml filename="pkginstall.html"?>
<title>The pkginstall framework</title>

<para>This chapter describes the framework known as
<literal>pkginstall</literal>, whose key features are:</para>

<itemizedlist>

  <listitem>
    <para>Generic installation and manipulation of directories and files
    outside the pkgsrc-handled tree, <varname>LOCALBASE</varname>.</para>
  </listitem>

  <listitem>
    <para>Automatic handling of configuration files during installation,
    provided that packages are correctly designed.</para>
  </listitem>

  <listitem>
    <para>Generation and installation of system startup scripts.</para>
  </listitem>

  <listitem>
    <para>Registration of system users and groups.</para>
  </listitem>

  <listitem>
    <para>Registration of system shells.</para>
  </listitem>

  <listitem>
    <para>Automatic updating of fonts databases.</para>
  </listitem>

</itemizedlist>

<para>The following sections inspect each of the above points in detail.</para>

<para>You may be thinking that many of the things described here could be
easily done with simple code in the package's post-installation target
(<literal>post-install</literal>).  <emphasis>This is incorrect</emphasis>,
as the code in them is only executed when building from source.  Machines
using binary packages could not benefit from it at all (as the code itself
could be unavailable).  Therefore, the only way to achieve any of the items
described above is by means of the installation scripts, which are
automatically generated by pkginstall.</para>

<!-- ================================================================== -->

<sect1 id="files-and-dirs-outside-prefix">
<title>Files and directories outside the installation prefix</title>

<para>As you already know, the <filename>PLIST</filename> file holds a list
of files and directories that belong to a package.  The names used in it
are relative to the installation prefix (<filename>${PREFIX}</filename>),
which means that it cannot register files outside this directory (absolute
path names are not allowed).  Despite this restriction, some packages need
to install files outside this location; e.g., under
<filename>${VARBASE}</filename> or
<filename>${PKG_SYSCONFDIR}</filename>.  The only way to achieve this
is to create such files during installation time by using
installation scripts.</para>

<para>The generic installation scripts are shell scripts that can
contain arbitrary code.  The list of scripts to execute is taken from
the <varname>INSTALL_FILE</varname> variable, which defaults to
<filename>INSTALL</filename>.  A similar variable exists for package
removal (<varname>DEINSTALL_FILE</varname>, whose default is
<filename>DEINSTALL</filename>).  These scripts can run arbitrary
commands, so they have the potential to create and manage files
anywhere in the file system.</para>

<para>Using these general installation files is not recommended, but
may be needed in some special cases.  One reason for avoiding them is
that the user has to trust the packager that there is no unwanted or
simply erroneous code included in the installation script. Also,
previously there were many similar scripts for the same functionality,
and fixing a common error involved finding and changing all of
them.</para>

<para>The pkginstall framework offers another, standardized way.  It
provides generic scripts to abstract the manipulation of such files
and directories based on variables set in the package's
<filename>Makefile</filename>.  The rest of this section describes
these variables.</para>

<!-- ================================================================== -->

<sect2 id="dirs-outside-prefix">
<title>Directory manipulation</title>

<para>The following variables can be set to request the creation of
directories anywhere in the file system:</para>

<itemizedlist>

  <listitem>
    <para><varname>MAKE_DIRS</varname> and <varname>OWN_DIRS</varname>
    contain a list of directories that should be created and should attempt
    to be destroyed by the installation scripts.  The difference between
    the two is that the latter prompts the administrator to remove any
    directories that may be left after deinstallation (because they were
    not empty), while the former does not.</para>
  </listitem>

  <listitem>
    <para><varname>MAKE_DIRS_PERMS</varname> and
    <varname>OWN_DIRS_PERMS</varname> contain a list of tuples describing
    which directories should be created and should attempt to be destroyed
    by the installation scripts.  Each tuple holds the following values,
    separated by spaces: the directory name, its owner, its group and its
    numerical mode.  For example:</para>

<programlisting>
MAKE_DIRS_PERMS+=         ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700
</programlisting>

    <para>The difference between the two is exactly the same as their
    non-<varname>PERMS</varname> counterparts.</para>
  </listitem>

</itemizedlist>

</sect2>

<!-- ================================================================== -->

<sect2 id="files-outside-prefix">
<title>File manipulation</title>

<para>Creating non-empty files outside the installation prefix is tricky
because the <filename>PLIST</filename> forces all files to be inside it.
To overcome this problem, the only solution is to extract the file in the
known place (i.e., inside the installation prefix) and copy it to the
appropriate location during installation (done by the installation scripts
generated by pkginstall).  We will call the former the <emphasis>master
file</emphasis> in the following paragraphs, which describe the variables
that can be used to automatically and consistently handle files outside the
installation prefix:</para>

<itemizedlist>

  <listitem>
    <para><varname>CONF_FILES</varname> and
    <varname>REQD_FILES</varname> are pairs of master and target files.
    During installation time, the master file is copied to the target one
    if and only if the latter does not exist.  Upon deinstallation, the
    target file is removed provided that it was not modified by the
    installation.</para>

    <para>The difference between the two is that the latter prompts the
    administrator to remove any files that may be left after
    deinstallation (because they were not empty), while the former does
    not.</para>
  </listitem>

  <listitem>
    <para><varname>CONF_FILES_PERMS</varname> and
    <varname>REQD_FILES_PERMS</varname> contain tuples describing master
    files as well as their target locations.  For each of them, it also
    specifies their owner, their group and their numeric permissions, in
    this order.  For example:</para>

<programlisting>
REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700
</programlisting>

    <para>The difference between the two is exactly the same as their
    non-<varname>PERMS</varname> counterparts.</para>
  </listitem>

</itemizedlist>

</sect2>

</sect1>

<!-- ================================================================== -->

<sect1 id="conf-files">
<title>Configuration files</title>

<para>Configuration files are special in the sense that they are installed
in their own specific directory, <varname>PKG_SYSCONFDIR</varname>, and
need special treatment during installation (most of which is automated by
pkginstall).  The main concept you must bear in mind is that files marked
as configuration files are automatically copied to the right place (somewhere
inside <varname>PKG_SYSCONFDIR</varname>) during installation <emphasis>if
and only if</emphasis> they didn't exist before.  Similarly, they will not
be removed if they have local modifications.  This ensures that
administrators never lose any custom changes they may have made.</para>

<!-- ================================================================== -->

<sect2 id="conf-files-sysconfdir">
<title>How <varname>PKG_SYSCONFDIR</varname> is set</title>

<para>As said before, the <varname>PKG_SYSCONFDIR</varname> variable
specifies where configuration files shall be installed.  Its contents are
set based upon the following variables:</para>

<itemizedlist>

  <listitem>
    <para><varname>PKG_SYSCONFBASE</varname>: The configuration's root
    directory.  Defaults to <filename>${PREFIX}/etc</filename> although it may
    be overridden by the user to point to his preferred location (e.g.,
    <filename>/etc</filename>, <filename>/etc/pkg</filename>, etc.).
    Packages must not use it directly.</para>
  </listitem>

  <listitem>
    <para><varname>PKG_SYSCONFSUBDIR</varname>: A subdirectory of
    <varname>PKG_SYSCONFBASE</varname> under which the configuration files
    for the package being built shall be installed.  The definition of this
    variable only makes sense in the package's
    <filename>Makefile</filename> (i.e., it is not user-customizable).</para>

    <para>As an example, consider the Apache package,
    <filename role="pkg">www/apache2</filename>, which places its
    configuration files under the
    <filename>httpd/</filename> subdirectory of
    <varname>PKG_SYSCONFBASE</varname>.  This should be set in the package
    Makefile.</para>
  </listitem>

  <listitem>
    <para><varname>PKG_SYSCONFVAR</varname>: Specifies the name of the
    variable that holds this package's configuration directory (if
    different from <varname>PKG_SYSCONFBASE</varname>).  It defaults to
    <varname>PKGBASE</varname>'s value, and is always prefixed with
    <literal>PKG_SYSCONFDIR</literal>.</para>
  </listitem>

  <listitem>
    <para><varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname>: Holds the
    directory where the configuration files for the package identified by
    <varname>PKG_SYSCONFVAR</varname>'s shall be placed.</para>
  </listitem>

</itemizedlist>

<para>Based on the above variables, pkginstall determines the value of
<varname>PKG_SYSCONFDIR</varname>, which is the <emphasis>only</emphasis>
variable that can be used within a package to refer to its configuration
directory.  The algorithm used to set its value is basically the
following:</para>

<orderedlist>

  <listitem>
    <para>If <varname>PKG_SYSCONFDIR.${PKG_SYSCONFVAR}</varname> is set,
    its value is used.</para>
  </listitem>

  <listitem>
    <para>If the previous variable is not defined but
    <varname>PKG_SYSCONFSUBDIR</varname> is set in the package's
    <filename>Makefile</filename>, the resulting value is
    <filename>${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR}</filename>.</para>
  </listitem>

  <listitem>
    <para>Otherwise, it is set to
    <filename>${PKG_SYSCONFBASE}</filename>.</para>
  </listitem>

</orderedlist>

<para>It is worth mentioning that <filename>${PKG_SYSCONFDIR}</filename> is
automatically added to <filename>OWN_DIRS</filename>.  See <xref
linkend="dirs-outside-prefix" /> what this means.  This does not apply to
subdirectories of <filename>${PKG_SYSCONFDIR}</filename>, they still have to
be created with OWN_DIRS or MAKE_DIRS.</para>

</sect2>

<!-- ================================================================== -->

<sect2 id="conf-files-configure">
<title>Telling the software where configuration files are</title>

<para>Given that pkgsrc (and users!) expect configuration files to be in a
known place, you need to teach each package where it shall install its
files.  In some cases you will have to patch the package Makefiles to
achieve it.  If you are lucky, though, it may be as easy as passing an
extra flag to the configuration script; this is the case of GNU Autoconf-
generated files:</para>

<programlisting>
CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR}
</programlisting>

<para>Note that this specifies where the package has to <emphasis>look
for</emphasis> its configuration files, not where they will be originally
installed (although the difference is never explicit,
unfortunately).</para>

</sect2>

<!-- ================================================================== -->

<sect2 id="conf-files-patching">
<title>Patching installations</title>

<para>As said before, pkginstall automatically handles configuration files.
This means that <emphasis role="strong">the packages themselves must not
touch the contents of <filename>${PKG_SYSCONFDIR}</filename>
directly</emphasis>.  Bad news is that many software installation scripts
will, out of the box, mess with the contents of that directory.  So what is
the correct procedure to fix this issue?</para>

<para>You must teach the package (usually by manually patching it) to
install any configuration files under the examples hierarchy,
<filename>share/examples/${PKGBASE}/</filename>.  This way, the
<filename>PLIST</filename> registers them and the administrator always
has the original copies available.</para>

<para>Once the required configuration files are in place (i.e., under the
examples hierarchy), the pkginstall framework can use them as master copies
during the package installation to update what is in
<filename>${PKG_SYSCONFDIR}</filename>.  To achieve this, the variables
<varname>CONF_FILES</varname> and <varname>CONF_FILES_PERMS</varname> are
used.  Check out <xref linkend="files-outside-prefix" /> for information
about their syntax and their purpose.  Here is an example, taken from the
<filename role="pkg">mail/mutt</filename> package:</para>

<programlisting>
EGDIR=        ${PREFIX}/share/doc/mutt/samples
CONF_FILES=   ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc
</programlisting>

<para>Note that the <varname>EGDIR</varname> variable is specific to that
package and has no meaning outside it.</para>

</sect2>

<!-- ================================================================== -->

<sect2 id="conf-files-disable">
<title>Disabling handling of configuration files</title>

<!-- XXX This doesn't really belong here -->

<para>The automatic copying of config files can be toggled by setting the
environment variable <varname>PKG_CONFIG</varname> prior to package
installation.</para>

</sect2>

</sect1>

<!-- ================================================================== -->

<sect1 id="rcd-scripts">
<title>System startup scripts</title>

<para>System startup scripts are special files because they must be
installed in a place known by the underlying OS, usually outside the
installation prefix.  Therefore, the same rules described in <xref
linkend="files-and-dirs-outside-prefix" /> apply, and the same solutions
can be used.  However, pkginstall provides a special mechanism to handle
these files.</para>

<para>In order to provide system startup scripts, the package has
to:</para>

<orderedlist>

  <listitem>
    <para>Store the script inside <filename>${FILESDIR}</filename>, with
    the <literal>.sh</literal> suffix appended.  Considering the
    <filename role="pkg">print/cups</filename> package as an example, it has a
    <filename>cupsd.sh</filename> in its files directory.</para>
  </listitem>

  <listitem>
    <para>Tell pkginstall to handle it, appending the name of the script,
    without its extension, to the <varname>RCD_SCRIPTS</varname> variable.
    Continuing the previous example:</para>

<programlisting>
RCD_SCRIPTS+=   cupsd
</programlisting>
  </listitem>

</orderedlist>

<para>Once this is done, pkginstall will do the following steps for each
script in an automated fashion:</para>

<!-- XXX We should probably have a chapter describing how rc.d scripts are
     written. -->

<orderedlist>

  <listitem>
    <para>Process the file found in the files directory applying all the
    substitutions described in the <filename>FILES_SUBST</filename>
    variable.</para>
  </listitem>

  <listitem>
    <para>Copy the script from the files directory to the examples
    hierarchy, <filename>${PREFIX}/share/examples/rc.d/</filename>.  Note
    that this master file must be explicitly registered in the
    <filename>PLIST</filename>.</para>
  </listitem>

  <listitem>
    <para>Add code to the installation scripts to copy the startup script
    from the examples hierarchy into the system-wide startup scripts
    directory.</para>
  </listitem>

</orderedlist>

<!-- ================================================================== -->

<sect2 id="rcd-scripts-disable">
<title>Disabling handling of system startup scripts</title>

<!-- XXX This doesn't really belong here -->

<para>The automatic copying of config files can be toggled by setting the
environment variable <varname>PKG_RCD_SCRIPTS</varname> prior to package
installation.  Note that the scripts will be always copied inside the
examples hierarchy, <filename>${PREFIX}/share/examples/rc.d/</filename>, no
matter what the value of this variable is.</para>

</sect2>

</sect1>

<!-- ================================================================== -->

<sect1 id="users-and-groups">
<title>System users and groups</title>

<para>If a package needs to create special users and/or groups during
installation, it can do so by using the pkginstall framework.</para>

<para>Users can be created by adding entries to the
<varname>PKG_USERS</varname> variable.  Each entry has the following
syntax:</para>

<programlisting>
user:group
</programlisting>

<para>Further specification of user details may be done by setting
per-user variables.
<varname>PKG_UID.<replaceable>user</replaceable></varname> is the
numeric UID for the user.
<varname>PKG_GECOS.<replaceable>user</replaceable></varname> is the
user's description or comment.
<varname>PKG_HOME.<replaceable>user</replaceable></varname> is the
user's home directory, and defaults to
<filename>/nonexistent</filename> if not specified.
<varname>PKG_SHELL.<replaceable>user</replaceable></varname> is the
user's shell, and defaults to <filename>/sbin/nologin</filename> if
not specified.</para>

<para>Similarly, groups can be created by adding entries to the
<varname>PKG_GROUPS</varname> variable, whose syntax is:</para>

<programlisting>
group
</programlisting>

<para>The numeric GID of the group may be set by defining
<varname>PKG_GID.<replaceable>group</replaceable></varname>.</para>

<para>If a package needs to create the users and groups at an earlier
stage, then it can set <varname>USERGROUP_PHASE</varname> to
either <literal>configure</literal> or <literal>build</literal> to
indicate the phase before which the users and groups are created.  In
this case, the numeric UIDs and GIDs of the created users and groups
are automatically hardcoded into the final installation scripts.</para>

</sect1>

<!-- ================================================================== -->

<sect1 id="shells">
<title>System shells</title>

<para>Packages that install system shells should register them in the shell
database, <filename>/etc/shells</filename>, to make things easier to the
administrator.  This must be done from the installation scripts to keep
binary packages working on any system.  pkginstall provides an easy way to
accomplish this task.</para>

<para>When a package provides a shell interpreter, it has to set the
<varname>PKG_SHELL</varname> variable to its absolute file name.  This will
add some hooks to the installation scripts to handle it.  Consider the
following example, taken from <filename role="pkg">shells/zsh</filename>:</para>

<programlisting>
PKG_SHELL=      ${PREFIX}/bin/zsh
</programlisting>

<!-- ================================================================== -->

<sect2 id="shells-disable">
<title>Disabling shell registration</title>

<!-- XXX This doesn't really belong here -->

<para>The automatic registration of shell interpreters can be disabled by
the administrator by setting the <filename>PKG_REGISTER_SHELLS</filename>
environment variable to <literal>NO</literal>.</para>

</sect2>

</sect1>

<!-- ================================================================== -->

<sect1 id="fonts">
<title>Fonts</title>

<para>Packages that install X11 fonts should update the database files
that index the fonts within each fonts directory.  This can easily be
accomplished within the pkginstall framework.</para>

<para>When a package installs X11 fonts, it must list the directories in
which fonts are installed in the
<varname>FONTS_DIRS.<replaceable>type</replaceable></varname> variables,
where <replaceable>type</replaceable> can be one of <quote>ttf</quote>,
<quote>type1</quote> or <quote>x11</quote>.  This will add hooks to the
installation scripts to run the appropriate commands to update the fonts
database files within each of those directories.  For convenience, if the
directory path is relative, it is taken to be relative to the package's
installation prefix.  Consider the following example, taken from <filename
role="pkg">fonts/dbz-ttf</filename>:</para>

<programlisting>
FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF
</programlisting>

<!-- ================================================================== -->

<sect2 id="fonts-disable">
<title>Disabling automatic update of the fonts databases</title>

<!-- XXX This doesn't really belong here -->

<para>The automatic update of fonts databases can be disabled by
the administrator by setting the <filename>PKG_UPDATE_FONTS_DB</filename>
environment variable to <literal>NO</literal>.</para>

</sect2>

</sect1>

</chapter>