Considerações antes de construir um 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 6Técnicas avançadas para a criação de pacotes.

Fazer com que os pacotes possam ser instalados remotamente

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.

Otimizar as configurações servidor-cliente

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.

Pacotes por limites funcionais

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.

Pacotes com limites de royalty

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.

Pacotes por dependências de sistema

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.

Eliminar sobreposições em pacotes

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.

Pacotes com limites de localização

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.