test

Guia do Desenvolvedor de Empacotamento de Aplicativos

Capítulo 5 Estudos de caso de criação de pacote

Este capítulo oferece estudos de caso para mostrar exemplos de empacotamento tais como instalar objetos condicionalmente, determinar em tempo de execução quantos arquivos criar e modificar um arquivo de dados existente durante a instalação e a remoção do pacote.

Cada estudo de caso começa com uma descrição, seguida de uma lista das técnicas de empacotamento usadas, uma descrição narrativa da abordagem adotada ao usar tais técnicas e scripts e arquivos de amostra associados ao estudo de caso.

A lista abaixo traz os estudos de caso encontrados neste capítulo.

Solicitando entrada do administrador

O pacote deste estudo de caso possui três tipos de objetos. O administrador pode escolher qual dos três tipos instalar e onde colocar os objetos na máquina de instalação.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Abordagem

Para configurar a instalação seletiva neste estudo de caso, você deve concluir as seguintes tarefas:

Arquivos de estudo de caso

O arquivo 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

O arquivo 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

O script 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

Observe que um script request pode sair sem deixar nenhum arquivo no sistema de arquivos. Em instalações em versões do Solaris anteriores a 2.5 e versões compatíveis (onde nenhum script checkinstall pode ser usado), o script request é o lugar correto para testar o sistema de arquivos de todas as formas necessárias para garantir que a instalação será bem-sucedida. Quando o script request existir com o código 1, a instalação sairá perfeitamente.

Estes arquivos de exemplo mostram o uso de caminhos paramétricos para estabelecer vários diretórios base. No entanto, o método preferido envolve o uso do parâmetro BASEDIR que é gerenciado e validado pelo comando pkgadd. Sempre que vários diretórios base forem usados, tenha especial cuidado em prover a instalação de várias versões e arquiteturas na mesma plataforma.

Criando um arquivo na instalação e salvando-o durante a remoção

Este estudo de caso cria um arquivo de banco de dados no tempo de instalação e salva um cópia do banco de dados quando o pacote é removido.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Abordagem

Para criar um arquivo de banco de dados na instalação e salvar uma cópia na remonação neste estudo de caso, você deve realizar as tarefas seguintes:

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo 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

O arquivo space 

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

O script de ação de classe 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

Isso ilustra uma instância rara na qual installf é apropriada em um script de ação de classe. Pelo fato do arquivo space ser usado para reservar espaço em um sistema de arquivos específico, este novo arquivo pode ser adicionado seguramente, mesmo se não estiver incluído no arquivo pkgmap.

O script de remoção 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

Definindo compatibilidades e dependências de pacotes

O pacote deste estudo de caso usa arquivos de informação opcionais para definir as compatibilidades e dependências do pacote, e para apresentar uma mensagem de copyright durante a instalação.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Para obter mais informações sobre estes arquivos, consulte Criando arquivos de informação.

Abordagem

Para satisfazer os requisitos da descrição, você deve:

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo 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

O arquivo compver 

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

O arquivo 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

Modificando um arquivo usando classes padrão e scripts de ação de classe

Este estudo de caso modifica um arquivo existente durante a instalação do pacote usando classes padrão e scripts de ação de classe. Usa um dos três métodos de modificação. Os outros dois métodos estão descritos em Modificando um arquivo usando a classe sed e um script postinstall e Modificando um arquivo usando a classe build. O arquivo modificado é /etc/inittab .

Técnicas

Este estudo de caso demonstra como usar os scripts de ação de classe de instalação e de remoção. Para obter informações, consulte Escrevendo scripts de ação de classe.

Abordagem

Para modificar /etc/inittab durante a instalação usando classes e scripts de ação de classe, você deve realizar as tarefas seguintes:

Este estudo de caso é mais complicado do que o estudo de caso a seguir, consulte Modificando um arquivo usando a classe sed e um script postinstall. Em vez de fornecer dois arquivos, são necessários três arquivos e o arquivo /etc/inittab integrado é, em realidade, apenas um espaço reservado contendo um fragmento da entrada que será inserida. Poderia ter sido colocado no arquivo i.inittab exceto que o comando pkgadd deve ter um arquivo para passar ao arquivo i.inittab. O procedimento de remoção também deve ser colocado em outro arquivo (r.inittab). Embora este método funcione bem, é melhor reservá-lo para os casos que envolvam instalações complicadas de vários arquivos. Consulte Modificando arquivos crontab durante a instalação.

O programa sed usado em Modificando um arquivo usando a classe sed e um script postinstall oferece suporte a várias instâncias de pacote desde que o comentário no final da entrada inittab esteja baseado em uma instância de pacote. O estudo de caso em Modificando um arquivo usando a classe build mostra uma abordagem mais dinâmica para editar /etc/inittab durante a instalação.

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo prototype 

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

O script de ação de classe de instalação 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

O script de ação de classe de remoção 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

O arquivo inittab 

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

Modificando um arquivo usando a classe sed e um script postinstall

Este estudo de caso modifica um arquivo que existe na máquina de instalação durante a instalação do pacote. Usa um dos três métodos de modificação. Os outros dois métodos estão descritos em Modificando um arquivo usando classes padrão e scripts de ação de classe e Modificando um arquivo usando a classe build. O arquivo modificado é /etc/inittab.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Abordagem

Para modificar /etc/inittab no momento da instalação usando a classe sed, você deve realizar as tarefas seguintes:

Esta abordagem de edição de /etc/inittab durante a instalação tem uma desvantagem. Você tem que distribuir um script completo (o script postinstall) simplesmente para realizar o comando init q.

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo prototype 

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

O script de ação de classe 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

O script postinstall 

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

Modificando um arquivo usando a classe build

Este estudo de caso modifica um arquivo que existe na máquina de instalação durante a instalação do pacote. Usa um dos três métodos de modificação. Os outros dois métodos estão descritos em Modificando um arquivo usando classes padrão e scripts de ação de classe e Modificando um arquivo usando a classe sed e um script postinstall. O arquivo modificado é /etc/inittab.

Técnicas

Este estudo de caso demonstra como usar a classe build. Para obter mais informações sobre a classe build, consulte O script de classe build.

Abordagem

Esta abordagem de modificação de /etc/inittab usa a classe build. Um script de classe build é executado com um script shell e sua saída se torna a nova versão do arquivo que está sendo executado. Em outras palavras, o arquivo de dados /etc/inittab distribuído com este pacote será executado e a saída de tal execução será /etc/inittab.

O script de classe build é executado durante a instalação e a remoção do pacote. O argumento install é passado para o arquivo se ele estiver sendo executado no tempo de instalação. Observe no script de classe build de amostra que as ações de instalação são definidas ao testar este argumento.

Para editar /etc/inittab usando a classe build, você deve realizar as tarefas seguintes:

Esta solução trata das desvantagens descritas nos estudos de caso em Modificando um arquivo usando classes padrão e scripts de ação de classe e em Modificando um arquivo usando a classe sed e um script postinstall. É necessário somente um arquivo breve (além dos arquivos pkginfo e prototype). O arquivo funciona com várias instâncias de um pacote desde que o parâmetro PKGINST seja usado, e o script postinstall não é necessário desde que o comando init q possa ser executado da classe build.

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo prototype 

i pkginfo
e build /etc/inittab ? ? ?

O arquivo 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

Modificando arquivos crontab durante a instalação

Este estudo de caso modifica arquivos crontab durante a instalação do pacote.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Abordagem

A forma mais eficiente de editar mais de um arquivo durante a instalação é definir uma classe e fornecer um script de ação de classe. Se você usou a abordagem da classe build, será necessário distribuir um script de classe build para cada arquivo crontab editado. A definição de uma classe cron proporciona uma abordagem mais geral. Para editar arquivos crontab com esta abordagem, você deve:

Arquivos de estudo de caso

Os scripts i.cron e r.cron descritos abaixo são executados pelo superusuário. A edição de outro arquivo crontab do usuário como superusuário pode ter conseqüências imprevisíveis. Se necessário, altere a seguinte entrada em cada script de:

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

para

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

O comando pkginfo 

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

O arquivo prototype 

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

O script de ação de classe de instalação 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

O script de ação de classe de remoção 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

Arquivo 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

Arquivo 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
Observação –

Se a edição de um grupo de arquivos for aumentar o tamanho total do arquivo em mais de 10K, forneça um arquivo space para que o comando pkgadd possa permitir esse aumento. Para mais informações sobre o arquivo space, consulte Reservando espaço adicional em um sistema de destino.

Instalando e removendo um driver com scripts de procedimento

Este pacote instala um driver.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Para obter mais informações sobre estes scripts, consulte Escrevendo scripts de procedimento.

Abordagem

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo prototype

Para instalar um driver no momento da instalação, você deve incluir os arquivos de objeto e de configuração do driver no arquivo prototype.

Neste exemplo, o módulo executável do driver é nomeado buffer. O comando add_drv opera neste arquivo. O kernel usa o arquivo de configuração, buffer.conf, para ajudar a configurar o driver. 

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

Ao observar o arquivo prototype deste exemplo, note o seguinte:

O script 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

O script 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

O script 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

Instalando um driver usando a classe sed e scripts de procedimento

Este estudo de caso descreve como instalar um driver usando a classe sed e scripts de procedimento. Também é diferente do estudo de caso anterior (consulte Instalando e removendo um driver com scripts de procedimento) porque este pacote está composto de objetos absolutos e relocáveis.

Técnicas

Este estudo de caso demonstra as seguintes técnicas:

Abordagem

Arquivos de estudo de caso

O arquivo pkginfo 

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

O arquivo prototype

Este estudo de caso, por exemplo, usa o layout de hierarquia dos objetos de pacote mostrados na figura abaixo.

Figura 5–1 Estrutura hierárquica do diretório do pacote

O contexto seguinte descreve o gráfico.

Os objetos de pacote são instalados nos mesmos locais que no diretório pkg acima. Os módulos do driver (sst e sst.conf) são instalados no /usr/kernel/drv e o arquivo incluído é instalado em /usr/include/sys/scsi/targets. Os arquivos sst, sst.conf e sst_def.h são objetos absolutos. O programa de teste, sstest.c, e seu diretório SUNWsst são relocáveis. O seu local de instalação é definido pelo parâmetro BASEDIR.

Os componentes restantes do pacote (todos os arquivos de controle) se encontram na parte superior do diretório do pacote na máquina de desenvolvimento, exceto o script de classe sed. Denomina-se devlink.tab depois do arquivo que ele modifica, e entra em etc, o diretório que contém o arquivo devlink.tab real.

Do diretório pkg, execute o comando pkgproto da seguinte forma:


find usr SUNWsst -print | pkgproto > prototype

A saída do comando acima se assemelha à saída seguinte:

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

Este arquivo prototype ainda não está completo. Para completar este arquivo, você precisa fazer as seguintes modificações:

Este é o arquivo prototype final:

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

Os pontos de interrogação na entrada de cada script sed indicam que as permissões de acesso e a propriedade do arquivo existentes na máquina de instalação não devem ser alterados.

O script de ação de classe sed (/etc/devlink.tab)

No exemplo de driver, um script de classe sed é usado para adicionar uma entrada ao arquivo /etc/devlink.tab no driver. Este arquivo é usado pelo comando devlinks para criar links simbólicos de /dev em /devices. Este é o script 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

O comando pkgrm não executa a remoção de parte do script. Você pode precisar adicionar uma linha ao script preremove para executar sed diretamente para remover a entrada do arquivo /etc/devlink.tab.

O script de instalação postinstall

Neste exemplo, o script precisa apenas executar o comando 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

O comando add_drv usa o parâmetro BASEDIR, de modo que o script tem que cancelar a definição de BASEDIR antes de executar o comando e restaurá-lo depois.

Uma das ações do comando add_drv é executar devlinks, que usa a entrada colocada em /etc/devlink.tab pelo script de classe sed para criar as entradas /dev no driver.

O código de saíca do script postinstall é importante. O código de saída 20 manda o comando pkgadd dizer ao usuário para reiniciar o sistema (necessário depois da instalação de um driver), e o código de saída 2 manda o comando pkgadd dizer ao usuário que a instalação falhou parcialmente.

O script de remoção preremove

No estudo de caso deste exemplo de driver, ele remove os links em /dev e executa o comando rem_drv no driver.

# 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

O script remove as entradas /dev. As entradas /devices são removidas pelo comando rem_drv.

O arquivo copyright

É um arquivo ASCII simples que contém o texto de um aviso de copyright. O aviso é exibido no início da instalação do pacote exatamente como aparece no arquivo.


	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.