test

Guia do Desenvolvedor de Empacotamento de Aplicativos

Não tradicional

A abordagem descrita nesta seção não se aplica a todos os pacotes, mas tem como resultado melhor desempenho durante a instalação em um ambiente heterogêneo. Uma pequena parte se aplica a pacotes entregues como parte do sistema operacional Solaris (pacotes incorporados). Entretanto, os pacotes avulsos podem praticar empacotamento não tradicional.

A razão pela qual se encoraja o uso de pacotes relocáveis é oferecer suporte a este requisito:

Quando um pacote é adicionado ou removido, os comportamentos desejáveis existentes dos produtos de software instalados não serão alterados.

Os pacotes avulsos devem estar em /opt de modo a garantir que o novo pacote não interfira nos produtos existentes.

Outra consideração sobre os pacotes compostos

Há duas regras a seguir ao construir um pacote composto funcional:

Em outras palavras, visto que “relocável” significa que o objeto pode ser instalado em qualquer parte e ainda funcionar, nenhum script de início executado por init no tempo de inicialização pode ser considerado relocável! Embora não exista nada de errado em especificar /etc/passwd como um caminho relativo no pacote entregue, há somente um lugar para o qual ele pode ir.

Fazendo nomes de caminho absolutos parecer relocáveis

Se for construir um pacote composto, os caminhos absolutos devem operar de modo que não interfiram no software instalado. Um pacote que pode estar totalmente contido em /opt contorna este problema, já que não há arquivos existentes no meio do caminho. Quando um arquivo em /etc estiver incluído no pacote, você deve garantir que nomes de caminho absolutos se comportem da mesma forma que os nomes de caminho relativos. Leve em consideração os dois exemplos seguintes.

Exemplo — Modificando um arquivo

Descrição

Uma entrada está sendo adicionada a uma tabela, ou o objeto é uma nova tabela que será provavelmente modificada por outros programas ou pacotes.

Implementação

Defina o objeto como tipo de arquivo e e pertencente à classe build, awk ou sed. O script que realiza esta tarefa deve remover a si mesmo de maneira tão eficaz como quando se adiciona.

Exemplo

Uma entrada precisa ser adicionada a /etc/vfstab em apoio ao novo disco rígido de estado sólido.

A entrada no arquivo pkgmap pode ser 


1 e sed /etc/vfstab ? ? ?

O script request pergunta ao operador se /etc/vfstab deve ser modificado pelo pacote. Se o operador responder “não”, então o script request imprimirá as instruções sobre como realizar o trabalho manualmente e executará 


echo "CLASSES=none" >> $1

Se o operador responder “sim”, então ele executa 


echo "CLASSES=none sed" >> $1

que ativa o script de ação de classe que fará as modificações necessárias. A classe sed significa que o arquivo de pacote /etc/vfstab é um programa sed que contém as operações de instalação e remoção do arquivo com o mesmo nome no sistema de destino.

Exemplo — Criando um novo arquivo

Descrição

O objeto é um arquivo totalmente novo que provavelmente não será editado mais adiante ou está substituindo um arquivo de outro pacote.

Implementação

Defina o objeto de pacote como tipo de arquivo f e o instale usando um script de ação de classe capaz de desfazer alterações.

Exemplo

Um novo arquivo de marca é requerido em /etc para proporcionar as informações necessárias para suportar o disco rígido de estado sólido, denominado /etc/shdisk.conf . A entrada no arquivo pkgmap pode ter esta aparência: 


 
.
.
.
1 f newetc /etc/shdisk.conf
.
.
.

O script de ação de classe i.newetc é responsável pela instalação e por qualquer outro arquivo que precise ir para /etc. Ele faz a verificação para se certificar de que não exista outro arquivo lá. Se não existir, ele simplesmente copia o novo arquivo no local. Se já existir um arquivo no local, ele fará o backup do arquivo existente antes de instalar o novo arquivo. O script r.newetc remove estes arquivos e restaura os originais, se requerido Abaixo se encontra o fragmento principal do script de instalação.

# i.newetc
while read src dst; do
	  if [ -f $dst ]; then
	    dstfile=`basename $dst`
	    cp $dst $PKGSAV/$dstfile
	  fi
	  cp $src $dst
done
 
if [ "${1}" = "ENDOFCLASS" ]; then
	  cd $PKGSAV
	  tar cf SAVE.newetc .
	  $INST_DATADIR/$PKG/install/squish SAVE.newetc
fi

Observe que este usa a variável de ambiente PKGSAV para armazenar o backup do arquivo que será substituído. Quando o argumento ENDOFCLASS é passado para o script, isso quer dizer que o comando pkgadd informa o script que estas são as últimas entradas desta classe, momento em que o script arquiva e compacta os arquivos salvos usando um programa privado de compactação armazenado no diretório de instalação do pacote.

Embora o uso da variável de ambiente PKGSAV não seja confiável durante a atualização de um pacote, se o pacote não for atualizado (através de um patch, por exemplo), o arquivo de backup é seguro. O seguinte script de remoção inclui o código para lidar com outros problemas — o fato de que as versões antigas do comando pkgrm não passem para os scripts o caminho correto da variável de ambiente PKGSAV.

O script de remoção pode ter esta aparência.

# r.newetc
 
# make sure we have the correct PKGSAV
if [ -d $PKG_INSTALL_ROOT$PKGSAV ]; then
	  PKGSAV="$PKG_INSTALL_ROOT$PKGSAV"
fi
 
# find the unsquish program
UNSQUISH_CMD=`dirname $0`/unsquish
 
while read file; do
	  rm $file
done
 
if [ "${1}" = ENDOFCLASS ]; then
	  if [ -f $PKGSAV/SAVE.newetc.sq ]; then
	     $UNSQUISH_CMD $PKGSAV/SAVE.newetc
	  fi
 
	  if [ -f $PKGSAV/SAVE.newetc ]; then
	     targetdir=dirname $file	# get the right directory
	     cd $targetdir
		    tar xf $PKGSAV/SAVE.newetc
		    rm $PKGSAV/SAVE.newetc
	  fi
fi

Este script usa um algoritmo privado desinstalado (unsquish) que está no diretório de instalação do banco de dados do pacote. Isso é feito automaticamente pelo comando pkgadd no tempo de instalação. Todos os scripts não reconhecidos especificamente como somente de instalação pelo comando pkgadd são deixados neste diretório para serem usados pelo comando pkgrm. Você não pode saber onde tal diretório está, mas pode ter certeza de que está fixo e contém todos os arquivos de informação e scripts de instalação necessários do pacote. O script encontra o diretório devido ao fato de que o script de ação de classe está com certeza sendo executado a partir do diretório que contém o programa unsquish.

Observe, também, que este script não apenas supõe que o diretório de destino é /etc. Ele pode realmente estar em /export/root/client2/etc . O diretório correto pode ser construído de duas formas.

Usando esta abordagem para cada objeto absoluto do pacote, você pode ter certeza de que o comportamento atual desejável é inalterado ou, pelo menos, recuperável.

Exemplo — Um pacote composto

Abaixo se encontra um exemplo dos arquivos pkginfo e pkgmap de um pacote composto.

O arquivo pkginfo 

PKG=SUNWstuf
NAME=software stuff 
ARCH=sparc
VERSION=1.0.0,REV=1.0.5
CATEGORY=application
DESC=a set of utilities that do stuff
BASEDIR=/opt
VENDOR=Sun Microsystems, Inc.
HOTLINE=Please contact your local service provider
EMAIL=
MAXINST=1000
CLASSES=none daemon
PSTAMP=hubert990707141632

O arquivo pkgmap 

: 1 1758
1 d none SUNWstuf/EZstuf 0775 root bin
1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229
1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229
1 d none SUNWstuf/HRDstuf 0775 root bin
1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229
1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229
1 d none /etc	? ? ?
1 d none /etc/rc2.d ? ? ?
1 e daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443
1 i i.daemon 509 39560 752978103
1 i pkginfo 348 28411 760740163
1 i postinstall 323 26475 751309908
1 i postremove 402 33179 751309945
1 i preinstall 321 26254 751310019
1 i preremove 320 26114 751309865
1 i r.daemon 320 24573 742152591

Enquanto S70dostuf pertence à classe daemon, os diretórios que lidam com ele (que já estão no local no tempo de instalação) pertencem à classe none. Mesmo se os diretórios forem exclusivos deste pacote, você deve deixá-los na classe none. A razão disso é que os diretórios precisam ser criados primeiro e excluídos por último, e tal ação é sempre válida para a classe none. O comando pkgadd cria diretórios. Eles não são copiados do pacote e não são passados a um script de ação de classe a ser criado. Em vez disso, eles são criados pelo comando pkgadd antes que ele chame o script de ação de classe de instalação, e o comando pkgrm exclui os diretórios após a conclusão do script de ação de classe de remoção.

Isso significa que, se um diretório de uma classe especial contiver objetos na classe none, quando o comando pkgrm tenta remover o diretório, ele falha porque o diretório não estará vazio a tempo. Se um objeto de classe none estiver para ser inserido em um diretório de alguma classe especial, tal diretório não existirá a tempo para aceitar o objeto. O comando pkgadd não criará o diretório instantaneamente durante a instalação do objeto e pode não ser capaz de sincronizar os atributos de tal diretório quando exibir finalmente a definição de pkgmap.

Observação –

Ao atribuir um diretório a uma classe, lembre-se sempre da ordem de criação e exclusão.