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:

• Uso de nomes de caminho paramétricos (variáveis em nomes de caminho do objeto) usados para estabelecer vários diretórios base

  Para obter informações sobre nomes de caminho paramétricos, consulte Nomes de caminho paramétrico.

• Uso de um script request para solicitar entrada do administrador

  Para obter informações sobre scripts request, consulte Escrevendo um script request.

• Definição de valores condicionais para um parâmetro de instalação.

Abordagem

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

• Definir uma classe para cada tipo de objeto que pode ser instalado.

  Neste estudo de caso, os três tipos de objetos são as executáveis do pacote, as páginas do manual e as executáveis emacs. Cada tipo possui sua própria classe: bin, man e emacs, respectivamente. Observe que no arquivo prototype todos os arquivos do objeto pertencem a uma dessas três classes.

• Inicializar o parâmetro CLASSES no arquivo pkginfo como nulo.

  Normalmente, quando uma classe é definida, ela deve ser listada no parâmetro CLASSES no arquivo pkginfo. Do contrário, nenhum objeto é instalado em tal classe. Para este estudo de caso, o parâmetro é inicialmente definido como nulo, o que significa que nenhum objeto será instalado. O parâmetro CLASSES será alterado pelo script request, com base nas escolhas do administrador. Desta forma, o parâmetro CLASSES é definido somente para os tipos de objetos que o administrador deseja instalar.

  ---

  Observação –

  Em geral, é uma boa idéia definir os parâmetros com um valor padrão. Se este pacote tiver componentes comuns aos três tipos de objetos, você pode atribuí-los a classe none e, então, definir o parâmetro CLASSES igual a none.

  ---

• Inserir nomes de caminho paramétricos no arquivo prototype.

  O script request define estas variáveis de ambiente com o valor fornecido pelo administrador. Nesse caso, o comando pkgadd resolve estas variáveis de ambiente no tempo de instalação e sabe onde instalar o pacote.

  As três variáveis de ambiente usadas deste exemplo estão definidas com seus valores padrão no arquivo pkginfo e servem para os seguintes propósitos:

  • $NCMPBIN define o local das executáveis do objeto

  • $NCMPMAN define o local das páginas do manual

  • $EMACS define o local das executáveis emacs

  O arquivo prototype do exemplo mostra como definir os nomes de caminho do objeto com as variáveis.

• Criar um script request para perguntar ao administrador que partes do pacote devem ser instaladas e onde devem ser colocadas.

  O script request deste pacote faz duas perguntas ao administrador:

  • Esta parte do pacote deve ser instalada?

    Quando a resposta for sim, o nome de classe apropriado é adicionado ao parâmetro CLASSES. Por exemplo, quando o administrador opta por instalar as páginas do manual associadas a este pacote, a classe man é adicionada ao parâmetro CLASSES.

  • Se afirmativo, onde esta parte deve ser colocada?

    A variável de ambiente apropriada é definida de acordo com a resposta a esta pergunta. No exemplo da página do manual, a variável $NCMPMAN é definida como o valor da resposta.

  Estas duas perguntas são repetidas em cada um dos três tipos de objetos.

  No final do script request, os parâmetros são disponibilizados para o ambiente de instalação do comando pkgadd e qualquer outro script de empacotamento. O script request faz isso gravando estas definições no arquivo fornecido pelo utilitário de chamada. Para este estudo de caso, não é fornecido nenhum outro script.

  Ao observar o script request deste estudo de caso, note que as perguntas são geradas pelas ferramentas de validação de dados ckyorn e ckpath. Para obter mais informações sobre estas ferramentas, consulte ckyorn(1) e ckpath(1).

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.