Product SiteDocumentation Site

15.2. Construindo seu Primeiro Pacote

15.2.1. Meta-pacotes ou falsos pacotes

Pacotes falsos e meta-pacotes são similares, ambos são shells vazios que somente existem para efeito dos metadados que existem na pilha de gerenciamento de pacotes.
O propósito de um pacote falso é enganar o dpkg e o apt para acreditarem que algum pacote está instalado mesmo que em realidade seja apenas um shell vazio. Isto permite satisfazer dependências num pacote quando o programa correspondente foi instalado fora do escopo do sistema de pacotes. Este método funciona, porém deve mesmo assim ser evitado sempre que possível, já que não garantias de que o programa instalado manualmente se comportará exatamente como o pacote correspondente faria e outros pacotes dependentes dele poderiam não funcionar corretamente.
De outra maneira, um meta-pacote existe em sua maioria como uma coleção de dependências, então instalando um meta-pacote na verdade trará um conjunto de pacotes em um único passo.
Ambos os tipos de pacotes podem ser criados pelos comandos equivs-control e equivs-build (do pacote equivs package). O comando equivs-control arquivo cria um arquivo de cabeçalho de pacotes Debian que deve ser editado para conter o nome do pacote desejado, seu número de versão, o nome do mantenedor, suas dependências e sua descrição. Outros campos, sem um valor padrão são opcionais e podem ser excluídos. Os campos Copyright, Changelog, Readme e Extra-Files não são campos padrões nos pacotes Debian; eles só fazem sentido no âmbito da equivs-build, e eles não serão mantidos nos cabeçalhos do pacote gerados.

Exemplo 15.2. Cabeçalho do pacote falso libxml-libxml-perl

Section: perl
Priority: optional
Standards-Version: 3.8.4

Package: libxml-libxml-perl
Version: 1.57-1
Maintainer: Raphael Hertzog <hertzog@debian.org>
Depends: libxml2 (>= 2.6.6)
Architecture: all
Description: Fake package - módulo instalado manualmente em site_perl
  Este é um pacote falso para deixar o sistema de empacotamento
  acreditando que este pacote Debian está instalado.
 .
Na verdade, o pacote não está instalado desde uma versão mais recente
  do módulo que foi manualmente compilada & instalada no
  diretório site_perl.
O próximo passo é gerar o pacote Debian com o comando equivs-build arquivo. Voilà: o pacote foi criado no diretório atual e pode ser manejado como qualquer outro pacote Debian seria.

15.2.2. Depósito Simples de Arquivos

Os administradores da Falcot Corp precisam criar um pacote Debian para facilitar a instalação de um conjunto de documentos em um grande número de máquina. O administrador responsável por essa tarefa primeiramente lê o “New Maintainer's Guide”, e então começa a trabalhar no seu primeiro pacote.
O primeiro passo é criar um diretório falcot-data-1.0 que conterá o pacote fonte. O pacote irá logicamente, ser chamado falcot-data e terá o número de versão 1.0. O administrador então coloca os documentos em um subdiretório data. Então ele chama o comando dh_make (do pacote dh-make) para adicionar os arquivos necessários para o processo de criação do pacote, o qual será armazenado em um subdiretório debian:
$ cd falcot-data-1.0
$ dh_make --native

Type of package: único binário, binário indep, binário múltiplo, biblioteca, módulo do kernel, patch para o kernel ou cdbs?
Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch or cdbs?
 [s/i/m/l/k/n/b] i
Maintainer name : Raphael Hertzog
Email-Address   : hertzog@debian.org
Date            : Mon, 11 Apr 2011 15:11:36 +0200
Package Name    : falcot-data
Version         : 1.0
License         : blank
Usind dpatch    : não
Type of Package : Independente
Pressione <enter> para confirmar:
Atualmente não há nível superior Makefile. Isto pode exigir um ajuste adicional.
Feito. Por favor, edite os arquivos no agora debian/subdiretório. Você também deve
verificar se o instalador falcot-data Makefiles  em $DESTDIR e não em /.
$
O tipo de pacote escolhido (binário único) indica que este pacote fonte irá gerar um único pacote binário dependendo da arquitetura (Arquitetura: qualquer). binário Indep atua como contraparte, e leva a um único pacote binário que não é dependente da arquitetura alvo ( Arquiitetura: Todas). Neste caso, a escolha último é mais relevante uma vez que o pacote contém apenas os documentos e não programas binários, para que possa ser usado de forma semelhante em computadores de todas arquitecturas.
O tipo múltiplo binário corresponde a um pacote fonte levando a vários pacotes binários. Um caso particular, biblioteca, é útil para bibliotecas compartilhadas, uma vez que precisa seguir regras rígidas do empacotamento. De forma semelhante, módulo do kernel deve ser restrito aos pacotes contendo módulos do kernel. Finalmente, cdbs é um pacote específico sistema de construção, é bastante flexível, mas requer uma certa quantidade de aprendizagem.
O comando dh_make criou uma pasta debian com muitos arquivos. Alguns são necessários, em particular rules, control, changelog e copyright. Arquivos com extensão ex são exemplos de arquivos que podem ser utilizados, modificando-os (e removendo a extensão), se for o caso. Quando eles não são necessários, entao é recomendado removê-los. O arquivo compat deve ser mantido, uma vez que é necessário para o funcionamento correto do conjunto de programas debhelper (todos começando com o prefixo dh_) utilizado em diferentes estágios do pacote do processo de construção.
O arquivo de direitos autorais deve conter informações sobre os autores dos documentos incluídos no pacote, e as licenças relacionadas. No nosso caso, estes são documentos internos e sua utilização é limitada para dentro da empresa Corp Falcot. O padrão changelog é geralmente apropriado; substituir o "lançamento inicial" com uma explicação mais detalhada e alterar da distribuição instável para interna é suficiente . O arquivo de controle também foi atualizado: a seção foi alterada para variada e a página inicial, os campos Vcs-Git e Vcs-Browser foram removidos. O campo Dependencia foi completado com iceweasel | www-browser, de modo a assegurar a disponibilidade de um navegador web capaz de exibir os documentos no pacote.

Exemplo 15.3. O arquivo control

Source: falcot-data
Section: misc
Priority: optional
Maintainer: Raphael Hertzog <hertzog@debian.org>
Build-Depends: debhelper (>= 7.0.50~)
Standards-Version: 3.8.4

Package: falcot-data
Architecture: all
Depends: iceweasel | www-browser, ${misc:Depends}
Description: Internal Falcot Corp Documentation
 This package provides several documents describing the internal
 structure at Falcot Corp.  This includes:
  - organization diagram
  - contacts for each department.
 .
 These documents MUST NOT leave the company.
 Their use is INTERNAL ONLY.

Exemplo 15.4. O arquivo changelog

falcot-data (1.0) internal; urgency=low

  * Lançamento inicial.
  * Comecemos por alguns documentos:
    - estrutura interna de empresa;
    - contatos para cada departamento.

 -- Raphael Hertzog <hertzog@debian.org>  Mon, 11 Apr 2011 20:46:33 +0200

Exemplo 15.5. O arquivo copyright

Este trabalho foi empacotado para o Debian por Raphael Hertzog <hertzog@debian.org>
na Seg, 11 Abril 2011 20:46:33 +0200

Direitos Autorais:

    Direitos Autorais (C) 2004-2011 Falcot Corp

Licença:

    Todos os direitos reservados.
O arquivo rules geralmente contém um conjunto de regras usado para configurar, construir e instalar o software em um subdiretório específico (nomeado após a geração do pacote binário). O conteúdo desta pasta é depois arquivado dentro do pacote Debian, como se fosse a raiz do sistema de arquivos. No nosso caso, os arquivos serão instalados na pasta debian/falcot-data/usr/share/falcot-data/, para que a instalação do pacote gerado irá implantar os arquivos em /usr/share/falcot-data/. O arquivo rules é utilizado como um Makefile, com alguns objetivos padrões (incluindoclean e binary, utilizados, respectivamente, para limpar a pasta de origem e gerar o pacote binário).
Embora esse arquivo seja o coração do processo, cada vez mais ele contém somente a informação mínima para executar um conjunto padrão de comandos provido pela ferramenta debhelper. Tal é o cado dos arquivos gerados pelo dh_make. Para instalar nossos arquivos, nós simplesmente configuramos o comportamento do comando dh_install criando o seguinte arquivo debian/falcot-data.install:
data/* usr/share/falcot-data/
Neste ponto, o pacote pode ser criado. Nós no entanto vamos adicionar um toque especial. Já que os administradores querem que os documentos sejam facilmente acessador a partir dos menus de Ajuda da interface gráfica, nós criaremos uma entrada no sistema de menu do Debian. Isto simplesmente é feito renomeando o debian/menu.ex sem sua extensão e editando o seguinte:

Exemplo 15.6. O arquivo menu

?package(falcot-data):needs=X11|wm section=Help\
  title="Internal Falcot Corp Documentation" \
  command="/usr/bin/x-www-browser /usr/share/falcot-data/index.html"
?package(falcot-data):needs=text section=Help\
  title="Internal Falcot Corp Documentation" \
  command="/usr/bin/www-browser /usr/share/falcot-data/index.html"
O campo needs, quando definido como X11|wm indica que esta entrada só faz sentido em uma interface gráfica. Portanto, só poderá ser integrado nos menus das aplicações (X11) e gerenciadores de janelas (por isso o wm). O estado do campo section onde a entrada deve ser exibida no menu. No nosso caso, a entrada será no menu Ajuda. O campo title contém o texto que será exibido no menu. Finalmente, o campo command descreve o comando a executar quando o usuário seleciona o item do menu.
A segunda entrada combina com a primeira, com pequenas adaptações para o modo texto do Linux.
Simplesmente criando o arquivo debian/menu é o suficiente para habilitar o menu no pacote, desde que o comando dh_installmenu seja automaticamente invocado por dh durante o processo de criação do pacote.
Nosso pacote fonte está pronto. Tudo o que sobrou fazer é gerar um pacote binário, com o mesmo método que usamos anteriormente para construir pacotes: executamos o comando dpkg-buildpackage -us -uc de dentro do diretório falcot-data-1.0.