Ignorar Links de Navegao | |
Sair do Modo de Exibio de Impresso | |
![]() |
Guia do desenvolvedor de empacotamento de aplicativos Oracle Solaris 10 1/13 Information Library (Português (Brasil)) |
Onde encontrar tarefas de empacotamento
Componentes de pacote necessários
Componentes de pacote opcionais
Arquivos de informação do pacote
Scripts de instalação do pacote
Considerações antes de construir um pacote
Fazer com que os pacotes possam ser instalados remotamente
Otimizar as configurações servidor-cliente
Pacotes por limites funcionais
Pacotes com limites de royalty
Pacotes por dependências de sistema
Comandos, arquivos e scripts do pacote
3. Melhorando a funcionalidade de um pacote (Tarefas)
4. Verificando e transferindo um pacote
5. Estudos de caso de criação de pacote
Antes de construir um pacote, é preciso decidir se o produto terá um ou mais pacotes. Observe que muitos pacotes pequenos demoram mais para serem instalados que um pacote grande. Embora criar um único pacote seja uma boa idéia, às vezes nem sempre é possível. Se decidir construir mais de um pacote, é preciso determinar como segmentar o código do aplicativo. Esta seção oferece uma lista de critérios para serem usados quando se está planejando construir um pacote.
Muitos dos critérios de empacotamento apresentam equiparações entre eles. Satisfazer todos os requisitos igualmente é muitas vezes difícil. Estes critérios são apresentados em ordem de importância. No entanto, esta seqüência serve apenas como um guia flexível dependendo das circunstâncias. Embora cada critério seja importante, depende de você otimizar estes requisitos para produzir um bom conjunto de pacotes.
Para obter mais idéias de criação, consulte o Capítulo 6, Técnicas avançadas para a criação de pacotes.
Todos os pacotes devem poder ser instalados remotamente. Ser remotamente instalável significa que o administrador que está instalando seu pacote pode instalá-lo em um sistema cliente, não necessariamente no sistema de arquivos raiz (/) onde o comando pkgadd está sendo executado.
Leve em consideração os vários tipos de configurações de software do sistema (por exemplo, servidor e sistema independentes) ao dispor os pacotes. Um bom design de empacotamento divide os arquivos afetados para otimizar a instalação de cada tipo de configuração. Por exemplo, o conteúdo dos sistemas de arquivos raiz (/) e /usr deve ser segmentado para que as configurações do servidor possam ser facilmente suportadas.
Os pacotes devem ser independentes e identificados claramente com um conjunto de funcionalidades. Por exemplo, um pacote que contém UFS deve conter todos os utilitários UFS e estar limitado somente a binários UFS.
Os pacotes devem estar organizados do ponto de vista do cliente dentro de unidades funcionais.
Use códigos que necessitam pagamentos de royalty devido a acordos contratuais em um pacote dedicado ou grupo de pacotes. Não disperse o código em mais pacotes do que o necessário.
Mantenha os binários dependentes de sistemas em pacotes dedicados. Por exemplo, o código do kernel deve estar em um pacote dedicado, com cada arquitetura de implementação formada por uma instância diferente de pacote. Esta regra também se aplica a binários de arquiteturas diferentes. Por exemplo, os binários de um sistema SPARC devem estar em um pacote e os binários de um sistema x86 devem estar em outro pacote.
Ao construir pacotes, elimine os arquivos duplicados sempre que possível. A duplicação desnecessária de arquivos causa dificuldades de suporte e versão. Se o seu produto tiver vários pacotes, compare repetidamente o conteúdo desses pacotes para procurar arquivos duplicados.
Itens específicos de localização devem estar em um pacote próprio. Um modelo de empacotamento ideal deve ter as localizações de um produto distribuídas como um pacote por localidade. Infelizmente, em alguns casos os limites organizacionais entram em conflito com os critérios de limites funcionais e de produto.
Os padrões internacionais também podem ser distribuídos em um pacote. Este design isola os arquivos necessários nas alterações de localizações e padroniza o formato de distribuição dos pacotes de localização.