svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
prototype(5)
prototype(5) File Formats prototype(5)
NAME
prototype - SVR4 package information file
DESCRIPTION
prototype is an ASCII file used to specify SVR4 package information.
Each entry in the file describes a single deliverable object. An object
can be a data file, directory, source file, executable object, and so
forth. This file is generated by the package developer.
Entries in a prototype file consist of several fields of information
separated by white space. Comment lines begin with a '#' and are ig‐
nored. The fields are described below and must appear in the order
shown.
part An optional field designating the part number in which the
object resides. A part is a collection of files and is the
atomic unit by which a package is processed. A developer
can choose criteria for grouping files into a part (for ex‐
ample, based on class). If this field is not used, part 1
is assumed.
ftype A one-character field that indicates the file type. Valid
values are:
b block special device
c character special device
d directory
e a file to be edited upon installation or removal (can
be shared by several packages)
f a standard executable or data file
i installation script or information file
l linked file
p named pipe
s symbolic link
v volatile file (one whose contents are expected to
change, like a log file)
x an exclusive directory accessible only by this package
class The installation class to which the file belongs. This name
can be no longer than 64 characters. The field is not spec‐
ified for installation scripts. (admin and all classes be‐
ginning with capital letters are reserved class names.)
pathname The pathname where the file resides on the target machine,
for example, /usr/bin/mail or bin/ras/proc. Relative path‐
names (those that do not begin with a slash) indicate that
the file is relocatable. The form
path1=path2
can be used for two purposes: to define a link and to de‐
fine local pathnames.
For linked files, path1 indicates the destination of the
link and path2 indicates the source file. (This format is
mandatory for linked files.)
For local pathnames, path1 indicates the pathname an object
should have on the machine where the entry is to be in‐
stalled and path2 indicates either a relative or fixed
pathname to a file on the host machine which contains the
actual contents.
A pathname can contain a variable specification of the form
$variable. If variable begins with a lowercase letter, it
is a build variable. If variable begins with an uppercase
letter, it is an install variable. Build variables are
bound at build time. If an install variable is known at
build time, its definition is inserted into the pkginfo(5)
file so that it is available at install time. If an install
variable is not known at build time, it is bound at install
time.
major The major device number. The field is only specified for
block or character special devices.
minor The minor device number. The field is only specified for
block or character special devices.
mode The octal mode of the file (for example, 0664). A question
mark (?) indicates that the mode is left unchanged, imply‐
ing that the file already exists on the target machine.
This field is not used for linked files or packaging infor‐
mation files.
The mode can be a variable specification of the form $vari‐
able. If variable begins with a lowercase letter, it is a
build variable. If variable begins with an uppercase let‐
ter, it is an install variable. Build variables are bound
at build time. If an install variable is known at build
time, its definition is inserted into the pkginfo(5) file
so that it is available at install time. If an install
variable is not known at build time, it is bound at install
time.
owner The owner of the file (for example, bin or root). The field
is limited to 14 characters in length. A question mark (?)
indicates that the owner is left unchanged, implying that
the file already exists on the target machine. This field
is not used for linked files or packaging information
files.
The owner can be a variable specification of the form
$variable. If variable begins with a lowercase letter, it
is a build variable. If variable begins with an uppercase
letter, it is an install variable. Build variables are
bound at build time. If an install variable is known at
build time, its definition is inserted into the pkginfo(5)
file so that it is available at install time. If an install
variable is not known at build time, it is bound at install
time.
group The group to which the file belongs (for example, bin or
sys). The field is limited to 14 characters in length. A
question mark (?) indicates that the group is left un‐
changed, implying that the file already exists on the tar‐
get machine. This field is not used for linked files or
packaging information files.
The group can be a variable specification of the form
$variable. If variable begins with a lowercase letter, it
is a build variable. If variable begins with an uppercase
letter, it is an install variable. Build variables are
bound at build time. If an install variable is known at
build time, its definition is inserted into the pkginfo(5)
file so that it is available at install time. If an install
variable is not known at build time, it is bound at install
time.
An exclamation point (!) at the beginning of a line indicates that the
line contains a command. These commands are used to incorporate files
in other directories, to locate objects on a host machine, and to set
permanent defaults. The following commands are available:
search Specifies a list of directories (separated by white
space) to search for when looking for file contents on
the host machine. The base name of the path field is ap‐
pended to each directory in the ordered list until the
file is located. Searches are not recursive.
include Specifies a pathname which points to another prototype
file to include. Note that search requests do not span
include files.
default Specifies a list of attributes (mode, owner, and group)
to be used by default if attribute information is not
provided for prototype entries which require the infor‐
mation. The defaults do not apply to entries in include
prototype files.
param=value Places the indicated parameter in the current environ‐
ment. Spans to subsequent included prototype files.
The above commands can have variable substitutions embedded within
them, as demonstrated in the two example prototype files below.
Before files are overwritten during installation, they are copied to a
temporary pathname. The exception to this rule is files whose mode in‐
cludes execute permission, unless the file is editable (that is, ftype
is e). For files which meet this exception, the existing version is
linked to a temporary pathname, and the original file is removed. This
allows processes which are executing during installation to be over‐
written.
EXAMPLES
Example 1 Example 1:
!PROJDIR=/usr/proj
!BIN=$PROJDIR/bin
!CFG=$PROJDIR/cfg
!LIB=$PROJDIR/lib
!HDRS=$PROJDIR/hdrs
!search /usr/myname/usr/bin /usr/myname/src /usr/myname/hdrs
i pkginfo=/usr/myname/wrap/pkginfo
i depend=/usr/myname/wrap/depend
i version=/usr/myname/wrap/version
d none /usr/wrap 0755 root bin
d none /usr/wrap/usr/bin 0755 root bin
! search $BIN
f none /usr/wrap/bin/INSTALL 0755 root bin
f none /usr/wrap/bin/REMOVE 0755 root bin
f none /usr/wrap/bin/addpkg 0755 root bin
!default 755 root bin
f none /usr/wrap/bin/audit
f none /usr/wrap/bin/listpkg
f none /usr/wrap/bin/pkgmk
# the following file starts out zero length but grows
v none /usr/wrap/logfile=/dev/null 0644 root bin
# the following specifies a link (dest=src)
l none /usr/wrap/src/addpkg=/usr/wrap/bin/rmpkg
! search $SRC
!default 644 root other
f src /usr/wrap/src/INSTALL.sh
f src /usr/wrap/src/REMOVE.sh
f src /usr/wrap/src/addpkg.c
f src /usr/wrap/src/audit.c
f src /usr/wrap/src/listpkg.c
f src /usr/wrap/src/pkgmk.c
d none /usr/wrap/data 0755 root bin
d none /usr/wrap/save 0755 root bin
d none /usr/wrap/spool 0755 root bin
d none /usr/wrap/tmp 0755 root bin
d src /usr/wrap/src 0755 root bin
Example 2 Example 2:
# this prototype is generated by 'pkgproto' to refer
# to all prototypes in my src directory
!PROJDIR=/usr/dew/projx
!include $PROJDIR/src/cmd/prototype
!include $PROJDIR/src/cmd/audmerg/protofile
!include $PROJDIR/src/lib/proto
USAGE
The prototype file is used when making legacy SVR4 packages designed
for older Solaris releases. Packages designed for Solaris 11 and later
releases use the IPS package system instead, and are installed and man‐
aged using the pkg(1) command. The IPS replacement for the prototype
file is the package manifest, described in pkg(7).
SEE ALSO
pkgmk(1), pkginfo(5)
NOTES
Normally, if a file is defined in the prototype file but does not ex‐
ist, that file is created at the time of package installation. However,
if the file pathname includes a directory that does not exist, the file
is not created. For example, if the prototype file has the following
entry:
f none /usr/dev/bin/command
and that file does not exist, it is created if the directory
/usr/dev/bin already exists or if the prototype also has an entry
defining the directory:
d none /usr/dev/bin
Oracle Solaris 11.4 3 Jan 2025 prototype(5)