test

Руководство разработчика по пакетированию приложений

Глава 5 Практические примеры создания пакета

В данной главе приводятся практические примеры случаев создания пакета, например, условная установка объектов, определение количества создаваемых файлов во время выполнения программы и изменение существующего файла данных во время установки и удаления пакета.

Рассмотрение каждого практического примера начинается с описания, затем следует перечень использованных методов создания пакета, описания подходов, использованных в этих методах, а также примеры файлов и сценариев, связанных с практическим примером.

В данной главе будут рассмотрены практические примеры.

Запрос ввода у администратора

В данном практическом примере пакет содержатся три типа объектов. Администратор может выбрать, какой из этих трех типов следует установить и в каком месте эти объекты будут располагаться на целевом компьютере.

Методы

В практическом примере применяются следующие методы:

Подход

Для настройки выборочной установки в этом практическом примере необходимо выполнить следующие задачи.

Файлы практических примеров

Файл pkginfo 

PKG=ncmp
NAME=NCMP Utilities
CATEGORY=application, tools
BASEDIR=/
ARCH=SPARC
VERSION=RELEASE 1.0, Issue 1.0
CLASSES=""
NCMPBIN=/bin
NCMPMAN=/usr/man
EMACS=/usr/emacs

Файл prototype 

i pkginfo
i request
x bin $NCMPBIN 0755 root other
f bin $NCMPBIN/dired=/usr/ncmp/bin/dired 0755 root other
f bin $NCMPBIN/less=/usr/ncmp/bin/less 0755 root other
f bin $NCMPBIN/ttype=/usr/ncmp/bin/ttype 0755 root other
f emacs $NCMPBIN/emacs=/usr/ncmp/bin/emacs 0755 root other
x emacs $EMACS 0755 root other
f emacs $EMACS/ansii=/usr/ncmp/lib/emacs/macros/ansii 0644 root other
f emacs $EMACS/box=/usr/ncmp/lib/emacs/macros/box 0644 root other
f emacs $EMACS/crypt=/usr/ncmp/lib/emacs/macros/crypt 0644 root other
f emacs $EMACS/draw=/usr/ncmp/lib/emacs/macros/draw 0644 root other
f emacs $EMACS/mail=/usr/ncmp/lib/emacs/macros/mail 0644 root other
f emacs $NCMPMAN/man1/emacs.1=/usr/ncmp/man/man1/emacs.1 0644 root other
d man $NCMPMAN 0755 root other
d man $NCMPMAN/man1 0755 root other
f man $NCMPMAN/man1/dired.1=/usr/ncmp/man/man1/dired.1 0644 root other
f man $NCMPMAN/man1/ttype.1=/usr/ncmp/man/man1/ttype.1 0644 root other
f man $NCMPMAN/man1/less.1=/usr/ncmp/man/man1/less.1 0644 inixmr other

Сценарий request 

trap 'exit 3' 15
# determine if and where general executables should be placed
ans=`ckyorn -d y \
-p "Should executables included in this package be installed"
` || exit $?
if [ "$ans" = y ]
then
   CLASSES="$CLASSES bin"
   NCMPBIN=`ckpath -d /usr/ncmp/bin -aoy \
   -p "Where should executables be installed"
   ` || exit $?
fi
# determine if emacs editor should be installed, and if it should
# where should the associated macros be placed
ans=`ckyorn -d y \
-p "Should emacs editor included in this package be installed"
` || exit $?
if [ "$ans" = y ]
then
   CLASSES="$CLASSES emacs"
   EMACS=`ckpath -d /usr/ncmp/lib/emacs -aoy \
   -p "Where should emacs macros be installed"
   ` || exit $?
fi

Обратите внимание, что выполнение сценария request может завершиться таким образом, что ни один из файлов не останется в файловой системе. Для установки в системе Solaris версий ниже 2.5 и совместимых версий (где нельзя использовать сценарий checkinstall), сценарий request подходит наилучшим образом для тестирования файловой системы с тем, чтобы обеспечить успешную установку. Если выполнение сценария request завершается с кодом 1, произойдет чистый выход из процесса установки.

В данных файлах примеров показано, как использовать параметрические пути для создания нескольких базовых каталогов. Однако предпочтительнее использовать параметр BASEDIR, который управляется и проверяется командой pkgadd. При использовании нескольких базовых каталогов необходимо особо тщательно следить за установкой нескольких версий и архитектур на одну и ту же платформу.

Создание файла во время установки и сохранение его во время удаления

В данном практическом примере в ходе установки будет создан файл базы данных и его копия сохранена после удаления пакета.

Методы

В практическом примере применяются следующие ниже методы.

Подход

Чтобы создать файл базы данных в ходе установки и сохранить его копию при удалении, необходимо выполнить следующие ниже задачи.

Файлы практических примеров

Файл pkginfo 

PKG=krazy
NAME=KrAzY Applications
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1
CLASSES=none cfgdata admin

Файл prototype 

i pkginfo
i request
i i.admin
i r.cfgdata
d none bin 555 root sys
f none bin/process1 555 root other
f none bin/process2 555 root other
f none bin/process3 555 root other
f admin bin/config 500 root sys
d admin cfg 555 root sys
f admin cfg/datafile1 444 root sys
f admin cfg/datafile2 444 root sys
f admin cfg/datafile3 444 root sys
f admin cfg/datafile4 444 root sys
d cfgdata data 555 root sys

Файл space 

# extra space required by config data which is
# dynamically loaded onto the system
data 500 1

Сценарий действия над классом i.admin 

# PKGINST parameter provided by installation service
# BASEDIR parameter provided by installation service
while read src dest
do
   cp $src $dest || exit 2
done
# if this is the last time this script will be executed
# during the installation, do additional processing here.
if [ "$1" = ENDOFCLASS ]
then
# our config process will create a data file based on any changes
# made by installing files in this class; make sure the data file
# is in class `cfgdata' so special rules can apply to it during
# package removal.
   installf -c cfgdata $PKGINST $BASEDIR/data/config.data f 444 root
   sys || exit 2
   $BASEDIR/bin/config > $BASEDIR/data/config.data || exit 2
   installf -f -c cfgdata $PKGINST || exit 2
fi
exit 0

Здесь продемонстрирован редкий случай, когда команда installf может быть необходима для сценария действия над классом. Поскольку файл space использовался для резервирования пространства в конкретной файловой системе, этот новый файл может быть добавлен в пакет несмотря на то, что он не включен в файл pkgmap.

Сценарий удаления r.cfgdata 

# the product manager for this package has suggested that
# the configuration data is so valuable that it should be
# backed up to $PKGSAV before it is removed!
while read path
do
# path names appear in reverse lexical order.
   mv $path $PKGSAV || exit 2
   rm -f $path || exit 2
done
exit 0

Определение совместимости и зависимостей пакета

Пакет в данном практическом примере использует необязательные информационные файлы для определения совместимости и зависимостей пакета, а также для вывода сообщения об авторских правах во время установки.

Методы

В практическом примере применяются следующие ниже методы.

Для получения дополнительной информации об этих файлах см. раздел Создание информационных файлов.

Подход

Для обеспечения соответствия требованиям, указанным в описании, необходимо выполнить следующие действия.

Файлы практических примеров

Файл pkginfo 

PKG=case3
NAME=Case Study #3
CATEGORY=application
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 3.0
CLASSES=none

Файл copyright 

Copyright (c) 1999 company_name
All Rights Reserved.
THIS PACKAGE CONTAINS UNPUBLISHED PROPRIETARY SOURCE CODE OF
company_name.
The copyright notice above does not evidence any
actual or intended publication of such source code

Файл compver 

Version 3.0
Version 2.3
Version 2.2
Version 2.1
Version 2.1.1
Version 2.1.3
Version 1.7

Файл depend 

P acu Advanced C Utilities
Issue 4 Version 1
P cc C Programming Language
Issue 4 Version 1
P dfm Directory and File Management Utilities
P ed Editing Utilities
P esg Extended Software Generation Utilities
Issue 4 Version 1
P graph Graphics Utilities
P rfs Remote File Sharing Utilities
Issue 1 Version 1
P rx Remote Execution Utilities
P sgs Software Generation Utilities
Issue 4 Version 1
P shell Shell Programming Utilities
P sys System Header Files
Release 3.1

Изменение файла с помощью стандартных классов и сценариев действий над классами

В данном практическом примере происходит изменение существующего файла в ходе установки пакета с помощью стандартных классов и сценариев действий над классами. Здесь используется один из трех способов изменения файла. Два других способа описаны в разделах Изменение файла с помощью класса sed и сценария postinstall и Изменение файла с помощью класса build. Изменяемый файл называется /etc/inittab.

Методы

В данном практическом примере показано, как использовать сценарии действий над классами в ходе установки и удаления пакета. Для получения дополнительной информации см. раздел Создание сценариев действий над классами.

Подход

Для изменения файла /etc/inittab в ходе установки с помощью классов и сценариев действий над классами необходимо выполнить следующие ниже задачи.

Данный практический пример более сложный, чем следующий; см. Изменение файла с помощью класса sed и сценария postinstall. Требуются три файла вместо двух, и поставляемый файл /etc/inittab в действительности является лишь местозаполнителем, содержащим фрагмент записи, которая будет вставлена. Эту запись можно было бы разместить в файле i.inittab, однако для этого команде pkgadd нужен файл, который будет передан в файл i.inittab. Кроме того, процедура удаления в этом случае должна быть размещена в отдельном файле (r.inittab). Хотя данный способ работает хорошо, лучше использовать его для случаев, когда требуется очень сложная установка большого количества файлов. См. раздел Изменение файлов crontab в ходе установки.

Программа sed, используемая в разделеИзменение файла с помощью класса sed и сценария postinstall, поддерживает большое количество экземпляров пакета, поскольку комментарий в конце записи inittab основан на экземпляре пакета. В практическом примере в разделе Изменение файла с помощью класса build используется более простой подход для редактирования файла /etc/inittab в ходе установки.

Файлы практических примеров

Файл pkginfo 

PKG=case5
NAME=Case Study #5
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=inittab

Файл prototype 

i pkginfo
i i.inittab
i r.inittab
e inittab /etc/inittab ? ? ?

Сценарий действия над классом при установке i.inittab 

# PKGINST parameter provided by installation service
while read src dest
do
# remove all entries from the table that
# associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest >
/tmp/$$itab ||
exit 2
sed -e "s/$/#$PKGINST" $src >> /tmp/$$itab ||
exit 2
mv /tmp/$$itab $dest ||
exit 2
done
if [ "$1" = ENDOFCLASS ]
then
/sbin/init q ||
exit 2
fi
exit 0

Сценарий действия над классом при удалении r.inittab 

# PKGINST parameter provided by installation service
while read src dest
do
# remove all entries from the table that
# are associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest >
/tmp/$$itab ||
exit 2
mv /tmp/$$itab $dest ||
exit 2
done
/sbin/init q ||
exit 2
exit 0

Файл inittab 

rb:023456:wait:/usr/robot/bin/setup

Изменение файла с помощью класса sed и сценария postinstall

В данном практическом примере происходит изменение файла, существующего на целевом компьютере в ходе установки пакета. Здесь используется один из трех способов изменения файла. Два других способа описаны в разделахИзменение файла с помощью стандартных классов и сценариев действий над классами и Изменение файла с помощью класса build. Изменяемый файл называется /etc/inittab.

Методы

В практическом примере применяются следующие ниже методы.

Подход

Для изменения файла /etc/inittab в ходе установки с помощью класса sed, необходимо выполнить следующие задачи:

Данный подход к изменению файла /etc/inittab в ходе установки имеет один недостаток - приходится поставлять полный сценарий (сценарий postinstall) лишь для того, чтобы выполнить команду init q.

Файлы практических примеров

Файл pkginfo 

PKG=case4
NAME=Case Study #4
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=sed

Файл prototype 

i pkginfo
i postinstall
e sed /etc/inittab ? ? ?

Сценарий действия над классом sed (/etc/inittab)

!remove
# remove all entries from the table that are associated
# with this package, though not necessarily just
# with this package instance
/^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d
!install
# remove any previous entry added to the table
# for this particular change
/^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d
# add the needed entry at the end of the table;
# sed(1) does not properly interpret the '$a'
# construct if you previously deleted the last
# line, so the command
# $a\
# rb:023456:wait:/usr/robot/bin/setup #ROBOT
# will not work here if the file already contained
# the modification. Instead, you will settle for
# inserting the entry before the last line!
$i\
rb:023456:wait:/usr/robot/bin/setup #ROBOT

Сценарий postinstall 

# make init re-read inittab
/sbin/init q ||
exit 2
exit 0

Изменение файла с помощью класса build

В данном практическом примере происходит изменение файла, существующего на целевом компьютере в ходе установки пакета. Здесь используется один из трех способов изменения файла. Два других способа описаны в разделах Изменение файла с помощью стандартных классов и сценариев действий над классами и Изменение файла с помощью класса sed и сценария postinstall. Изменяемый файл называется /etc/inittab.

Методы

В данном практическом примере показано, как использовать класс build. Для получения дополнительной информации о классе build см. раздел Сценарий класса build .

Подход

Данный подход к изменению /etc/inittab использует класс build. Сценарий класса build выполняется как сценарий интерпретатора команд, и результатом его выполнения становится новая версия исполняемого файла. Другими словами, файл данных /etc/inittab, поставляемый с этим пакетом, будет выполнен, и результатом этого выполнения станет файл /etc/inittab.

Сценарий класса build выполняется в ходе установки и удаления пакета. Параметр install передается файлу, если сценарий выполняется в ходе установки. В сценарии класса build обратите внимание на то, что действия по установке определяются посредством проверки этого параметра.

Для изменения файла /etc/inittab с помощью класса build необходимо выполнить следующие задачи.

Данное решение устраняет недостатки, описанные в практических примерах Изменение файла с помощью стандартных классов и сценариев действий над классами и Изменение файла с помощью класса sed и сценария postinstall. Требуется лишь один короткий файл (помимо файлов pkginfo и prototype). Этот файл работает с несколькими экземплярами пакета, поскольку используется параметр PKGINST, а сценарий postinstall не требуется, так как команду init q можно выполнить из сценария класса build.

Файлы практических примеров

Файл pkginfo 

PKG=case6
NAME=Case Study #6
CATEGORY=applications
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1d05
CLASSES=build

Файл prototype 

i pkginfo
e build /etc/inittab ? ? ?

Файл Build

# PKGINST parameter provided by installation service
# remove all entries from the existing table that
# are associated with this PKGINST
sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" /etc/inittab ||
exit 2
if [ "$1" = install ]
then
# add the following entry to the table
echo "rb:023456:wait:/usr/robot/bin/setup #$PKGINST" ||
exit 2
fi
/sbin/init q ||
exit 2
exit 0

Изменение файлов crontab в ходе установки

В данном практическом примере происходит изменение файлов crontab в ходе установки пакета.

Методы

В практическом примере применяются следующие методы:

Подход

Наиболее эффективным способом изменить несколько файлов в ходе установки является определение класса и создание сценария действия над классом. При использовании подхода с классом build необходимо поставлять один сценарий класса build для каждого изменяемого файла crontab. Более общим подходом будет создание класса cron. Для изменения файлов crontab при этом подходе необходимо:

Файлы практических примеров

Сценарии i.cron и r.cron, приведенные ниже, выполняются суперпользователем. Изменение суперпользователем файла crontab другого пользователя может привести к непредсказуемым результатам. При необходимости измените следующую запись в каждом сценарии:

crontab $user < /tmp/$$crontab ||

на

su $user -c "crontab /tmp/$$crontab" ||

Команда pkginfo 

PKG=case7
NAME=Case Study #7
CATEGORY=application
BASEDIR=/opt
ARCH=SPARC
VERSION=Version 1.0
CLASSES=cron

Файл prototype 

i pkginfo
i i.cron
i r.cron
e cron /var/spool/cron/crontabs/root ? ? ?
e cron /var/spool/cron/crontabs/sys ? ? ?

Установочный сценарий действия над классом i.cron 

# PKGINST parameter provided by installation service
while read src dest
do
user=`basename $dest` ||
exit 2
(crontab -l $user |
sed -e "/#$PKGINST$/d" > /tmp/$$crontab) ||
exit 2
sed -e "s/$/#$PKGINST/" $src >> /tmp/$$crontab ||
exit 2
crontab $user < /tmp/$$crontab ||
exit 2
rm -f /tmp/$$crontab
done
exit 0

Сценарий действия над классом при удалении r.cron 

# PKGINST parameter provided by installation service
while read path
do
user=`basename $path` ||
exit 2
(crontab -l $user |
sed -e "/#$PKGINST$/d" > /tmp/$$crontab) ||
exit 2
crontab $user < /tmp/$$crontab ||
exit 2
rm -f /tmp/$$crontab
done
exit

crontab Файл #1

41,1,21 * * * * /usr/lib/uucp/uudemon.hour > /dev/null
45 23 * * * ulimit 5000; /usr/bin/su uucp -c
"/usr/lib/uucp/uudemon.cleanup" >
/dev/null 2>&1
11,31,51 * * * * /usr/lib/uucp/uudemon.poll > /dev/null

crontab Файл #2

0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
Примечание –

Если при изменении группы файлов общий размер файлов увеличится более чем на 10 КБ, создайте файл space для того, чтобы команда pkgadd приняла во внимание это увеличение. Для получения дополнительной информации о файле space см. раздел Резервирование дополнительного места на диске на целевой системе.

Установка и удаление драйвера с помощью процедурных сценариев

Данный пакет производит установку драйвера.

Методы

В практическом примере применяются следующие методы:

Для получения дополнительной информации об этих сценариях см. раздел Создание процедурных сценариев .

Подход

Файлы практических примеров

Файл pkginfo 

PKG=bufdev
NAME=Buffer Device
CATEGORY=system
BASEDIR=/
ARCH=INTEL
VERSION=Software Issue #19
CLASSES=none

Файл prototype

Для установки драйвера в ходе установки пакета необходимо включить объект и файлы настройки драйвера в файл prototype.

В данном примере исполняемый модуль драйвера называется buffer. Команда add_drv работает с этим файлом. Ядро системы использует файл настройки buffer.conf для помощи в настройке драйвера. 

i pkginfo
i request
i postinstall
i preremove
f none $KERNDIR/buffer 444 root root
f none $KERNDIR/buffer.conf 444 root root

При рассмотрении файла prototype в этом примере обратите внимание на следующее:

Сценарий request 

trap 'exit 3' 15
# determine where driver object should be placed; location
# must be an absolute path name that is an existing directory
KERNDIR=`ckpath -aoy -d /kernel/drv -p \
“Where do you want the driver object installed”` || exit $?

# make parameters available to installation service, and
# so to any other packaging scripts
cat >$1 <<!

CLASSES='$CLASSES'
KERNDIR='$KERNDIR'
!
exit 0

Сценарий postinstall 

# KERNDIR parameter provided by `request' script
err_code=1                    # an error is considered fatal
# Load the module into the system
cd $KERNDIR
add_drv -m '* 0666 root sys' buffer || exit $err_code
# Create a /dev entry for the character node
installf $PKGINST /dev/buffer0=/devices/eisa/buffer*:0 s
installf -f $PKGINST

Сценарий preremove 

err_code=1                    # an error is considered fatal
# Unload the driver
rem_drv buffer || exit $err_code
# remove /dev file
removef $PKGINST /dev/buffer0 ; rm /dev/buffer0
removef -f $PKGINST

Установка драйвера с помощью класса sed и процедурных сценариев

В данном практическом примере описывается, как установить драйвер с помощью класса sed и процедурных сценариев. Он отличается от предыдущего практического примера (см. раздел Установка и удаление драйвера с помощью процедурных сценариев), поскольку данный пакет состоит как из абсолютных, так и перемещаемых объектов.

Методы

В практическом примере применяются следующие методы:

Подход

Файлы практических примеров

Файл pkginfo 

PKG=SUNWsst
NAME=Simple SCSI Target Driver
VERSION=1
CATEGORY=system
ARCH=sparc
VENDOR=Sun Microsystems
BASEDIR=/opt
CLASSES=sed

Файл prototype

В нашем практическом примере используется иерархическое распределение объектов пакета, как показано на рисунке ниже.

Рисунок 5–1 Структура каталогов иерархического пакета

Описание чертежа дается следующим контекстом.

Объекты пакета устанавливаются в то же место, в котором они расположены в каталоге pkgвыше. Модули драйвера ( sst и sst.conf) устанавливаются в каталог /usr/kernel/drv, а вложенный файл в каталог /usr/include/sys/scsi/targets. Файлы sst, sst.conf и sst_def.h являются абсолютными объектами. Тестовая программа sstest.c и ее каталог SUNWsst являются перемещаемыми; место их установки определяется параметром BASEDIR.

Оставшиеся компоненты пакета (все контрольные файлы) помещаются в каталог верхнего уровня пакета на компьютере разработчика, за исключением сценария класса sed. Сценарий называется devlink.tab в соответствии с изменяемым им файлом и помещается в каталог etc, содержащий действительный файл devlink.tab.

Из каталога pkg выполните команду pkgproto следующим образом:


find usr SUNWsst -print | pkgproto > prototype

Результат выполнения этой команды выглядит так:

d none usr 0775 pms mts
d none usr/include 0775 pms mts
d none usr/include/sys 0775 pms mts
d none usr/include/sys/scsi 0775 pms mts
d none usr/include/sys/scsi/targets 0775 pms mts
f none usr/include/sys/scsi/targets/sst_def.h 0444 pms mts
d none usr/kernel 0775 pms mts
d none usr/kernel/drv 0775 pms mts
f none usr/kernel/drv/sst 0664 pms mts
f none usr/kernel/drv/sst.conf 0444 pms mts
d none SUNWsst 0775 pms mts
f none SUNWsst/sstest.c 0664 pms mts

Создание данного файла prototype еще не завершено. Чтобы закончить создание этого файла, произведите следующие изменения:

Окончательный файл prototype выглядит так:

i pkginfo
i postinstall
i preremove
i copyright
e sed /etc/devlink.tab ? ? ?
f none /usr/include/sys/scsi/targets/sst_def.h 0644 bin bin
f none /usr/kernel/drv/sst 0755 root sys
f none /usr/kernel/drv/sst.conf 0644 root sys
d none SUNWsst 0775 root sys
f none SUNWsst/sstest.c 0664 root sys

Знаки вопроса в строке для сценария sed указывают, что права доступа и принадлежность существующего файла на целевом компьютере не должны изменяться.

Сценарий действия над классом sed(/etc/devlink.tab)

В примере с драйвером сценарий класса sed используется для добавления записи для драйвера в файл /etc/devlink.tab. Этот файл используется командой devlinks для создания символической ссылки из /dev в /devices. Сценарий sed выглядит так:

# sed class script to modify /etc/devlink.tab
!install
/name=sst;/d
$i\
type=ddi_pseudo;name=sst;minor=character	rsst\\A1

!remove
/name=sst;/d

Команда pkgrm не выполняет часть сценария, ответственную за удаление. Может понадобится добавление строки в сценарий preremove для того, чтобы класс sed удалил записи из файла /etc/devlink.tab напрямую.

Установочный сценарий postinstall

В данном практическом примере сценарию необходимо лишь выполнить команду add_drv.

# Postinstallation script for SUNWsst
# This does not apply to a client.
if [$PKG_INSTALL_ROOT = "/" -o -z $PKG_INSTALL_ROOT]; then
   SAVEBASE=$BASEDIR
   BASEDIR=””; export BASEDIR
   /usr/sbin/add_drv sst
   STATUS=$?
   BASEDIR=$SAVEBASE; export BASEDIR
   if [ $STATUS -eq 0 ]
   then
	     exit 20
   else
	     exit 2
   fi
else
   echo "This cannot be installed onto a client."
   exit 2
fi

Команда add_drv использует параметр BASEDIR, поэтому сценарию необходимо отменить установку параметра BASEDIR перед выполнением команды и восстановить его после выполнения.

Одним из действий, выполняемых командой add_drv, является выполнение команды devlinks, которая использует запись, размещенную в каталоге /etc/devlink.tab сценарием класса sed для создания записей /dev для драйвера.

Очень важен код выхода из сценария postinstall. Код выхода 20 указывает команде pkgadd известить пользователя о необходимости перезагрузки системы после установки драйвера, а код выхода 2 указывает команде pkgadd известить пользователя о том, что установка частично не удалась.

Сценарий удаления preremove

В практическом примере с данным драйвером этот сценарий удаляет ссылки в каталоге /dev и выполняет команду rem_drv на драйвере.

# Pre removal script for the sst driver
echo “Removing /dev entries”
/usr/bin/rm -f /dev/rsst*

echo “Deinstalling driver from the kernel”
SAVEBASE=$BASEDIR
BASEDIR=””; export BASEDIR
/usr/sbin/rem_drv sst
BASEDIR=$SAVEBASE; export BASEDIR

exit

Сценарий самостоятельно удаляет записи /dev; записи /devices удаляются командой rem_drv.

Файл copyright

Это простой файл ASCII, содержащий текст уведомления об авторских правах. Уведомление отображается в начале установки пакета точно в таком же виде, как оно представлено в файле.


	Copyright (c) 1999 Drivers-R-Us, Inc.
	10 Device Drive, Thebus, IO 80586

All rights reserved. This product and related documentation is
protected by copyright and distributed under licenses 
restricting its use, copying, distribution and decompilation. 
No part of this product or related documentation may be 
reproduced in any form by any means without prior written 
authorization of Drivers-R-Us and its licensors, if any.