svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
pkgmap(5)
pkgmap(5) File Formats pkgmap(5)
NAME
pkgmap - SVR4 package contents description file
DESCRIPTION
pkgmap is an ASCII file that provides a complete listing of the SVR4
package contents. It is automatically generated by pkgmk(1) using the
information in the prototype(5) file.
Each entry in pkgmap describes a single deliverable object file. A de‐
liverable object file includes shell scripts, executable objects, data
files, directories, and so forth. The entry consists of several fields
of information, each field separated by a space. The fields are de‐
scribed 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 the criteria for grouping files into a part (for
example, based on class). If no value is defined in this
field, part 1 is assumed.
ftype A one-character field that indicates the file type. Valid
values are listed below. File types are divided between
those that are not to be modified and those that are modi‐
fiable.
Files of the following types must never be modified:
b block special device
c character special device
d directory
f a standard executable file, data file, or other type
of file, the contents of which must never be modified.
i information file (such as a file containing a copy‐
right, list of dependencies, or package information)
or installation script (such as checkinstall, class
action [i.], pre/post install/remove), the contents of
which must never be modified.
l linked file
p named pipe
s symbolic link
x an exclusive directory accessible only by this package
Files of the following types can be modified:
e An editable file, intended to be edited (selectively
modified) after installation. An editable file is ex‐
pected to change on installation or removal, can be
shared by several packages, and must be installed by a
class action script. Examples are a configuration file
or a list of users.
v A volatile file, intended to be overwritten or ap‐
pended to after installation. A volatile file is not
expected to change on installation or removal, is not
preserved between installations, and can be installed
by a class action script. Examples are a log file or a
lock file.
Following package installation, the contents of files of
all types except e and v must not change. Any file that is
subject to change should be marked as e or v.
class The installation class to which the file belongs. This name
must contain only alphanumeric characters and be no longer
than 12 characters. It is not specified if the ftype is i
(information file).
pathname pathname may contain variables of the form $variable that
support install-time configuration of the file. variable
may be embedded in the pathname structure. (See proto‐
type(5) for definitions of variable specifications.)
Do not use the following reserved words in pathname, since
they are applied by pkgadd(8) using a different mechanism:
PKG_INSTALL_ROOT
BASEDIR
CLIENT_BASEDIR
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 will be left unchanged,
implying that the file already exists on the target ma‐
chine. This field is not used for linked files, packaging
information files, or non-installable files.
The mode can contain a variable specification. (See proto‐
type(5) for definitions of variable specifications.)
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 will be left unchanged or changed
to the owner stored in the package database, which could be
different from what is on the file system. When the ques‐
tion mark is used, it implies that the file is already on
the file system. This field is not used for linked files or
non-installable files. It is used optionally with a package
information file. If used, it indicates with what owner an
installation script will be executed.
The owner can contain a variable specification. (See proto‐
type(5) for definitions of variable specifications.)
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 will be left un‐
changed or changed to the owner stored in the package data‐
base, which could be different from what is on the file
system. When the question mark is used, it implies that the
file is already on the file system. This field is not used
for linked files or non-installable files. It is used op‐
tionally with a package information file. If used, it indi‐
cates with what group an installation script will be exe‐
cuted.
The group can contain a variable specification. (See proto‐
type(5) for definitions of variable specifications.)
size The actual size of the file in bytes. This field is not
specified for named pipes, special devices, directories or
linked files.
cksum The checksum of the file contents. This field is not speci‐
fied for named pipes, special devices, directories, or
linked files.
modtime The time of last modification, as reported by the stat(2)
function call. This field is not specified for named pipes,
special devices, directories, or linked files.
Each pkgmap file must have one line that provides information about the
number of parts, maximum size of parts that make up the package, and,
optionally, the size of the package after compression (where size is
given in 512-byte blocks). This line is in the following format:
: number_of_parts maximum_part_size compressed_pkg_size
Lines that begin with '#' are comment lines and are ignored.
When files are saved during installation before they are overwritten,
they are normally just copied to a temporary pathname. However, for
files whose mode includes execute permission (but which are not ed‐
itable), 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 overwritten.
EXAMPLES
Example 1 A Sample pkgmap File
: 2 500
1 i pkginfo 237 1179 541296672
1 d none bin 0755 root bin
1 f none bin/INSTALL 0755 root bin 11103 17954 541295535
1 f none bin/REMOVE 0755 root bin 3214 50237 541295541
1 l none bin/UNINSTALL=bin/REMOVE
1 f none bin/cmda 0755 root bin 3580 60325 541295567
1 f none bin/cmdb 0755 root bin 49107 51255 541438368
1 f class1 bin/cmdc 0755 root bin 45599 26048 541295599
1 f class1 bin/cmdd 0755 root bin 4648 8473 541461238
1 f none bin/cmde 0755 root bin 40501 1264 541295622
1 f class2 bin/cmdf 0755 root bin 2345 35889 541295574
1 f none bin/cmdg 0755 root bin 41185 47653 541461242
2 d class2 data 0755 root bin
2 p class1 data/apipe 0755 root other
2 d none log 0755 root bin
2 v none log/logfile 0755 root bin 41815 47563 541461333
2 d none save 0755 root bin
2 d none spool 0755 root bin
2 d none tmp 0755 root bin
USAGE
The pkgmap file is used when working with 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 pkgmap file
is the package manifest, described in pkg(7).
SEE ALSO
pkgmk(1), stat(2), pkginfo(5), prototype(5), pkgadd(8)
NOTES
The pkgmap file may contain only one entry per unique pathname.
Oracle Solaris 11.4 3 Jan 2025 pkgmap(5)