[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ próximo ]

Guia do Novo Mantenedor Debian
Capítulo 4 - Coisas necessárias no debian/


Agora existe um novo subdiretório no diretório-fonte do programa chamado 'debian'. Existem alguns arquivos nesse diretório que nós devemos editar para personalizar o comportamento do nosso pacote. Os mais importantes deles são 'control', 'changelog', 'copyright' e 'rules', que são necessários para todos os pacotes.


4.1 arquivo 'control'

Este arquivo contém vários valores que o dpkg, dselect e outras ferramentas de controle de pacotes irão utilizar para administrar o pacote.

Eis o arquivo de controle que o dh_make criou para nós:

       1  Source: gentoo
       2  Section: unknown
       3  Priority: optional
       4  Maintainer: Josip Rodin <joy-mg@debian.org>
       5  Build-Depends: debhelper (>> 3.0.0)
       6  Standards-Version: 3.5.2
       7
       8  Package: gentoo
       9  Architecture: any
       10 Depends: ${shlibs:Depends}
       11 Description: <insert up to 60 chars description>
       12  <insert long description, indented with spaces>

(eu adicionei os números das linhas)

As linhas 1-6 são as informações de controle para o pacote.

A linha 1 é o nome do pacote.

A linha 2 é a seção da distribuição em que o pacote será incluído.

Como você deve ter notado, o Debian é dividido em seções: main (a seção de software livre), non-free (os softwares gratuitos, mas não-livres) e contrib (software livre que depende de software não-livre). Dentro dessas, existem subseções lógicas que descrevem brevemente o tipo de pacote guardam. Então temos 'admin' para ferramentas de administradores, 'base' para ferramentas básicas, 'devel' para ferramentas de programação, 'doc' para documentação, 'libs' para bibliotecas, 'mail' para clientes e daemons de email, 'net' para aplicativos e daemons de rede, 'x11' para programas gráficos que não se enquadram em outras categorias, e muitas outras.

Então vamos alterá-lo para x11. (um prefixo 'main/' é implícito, e logo podemos omiti-lo.)

A linha 3 descreve o quão importante que o usuário instale este pacote. Leia o Debian-Policy para orientação no preenchimento desta lacuna. A prioridade 'optional' normalmente caberá para novos pacotes.

Seção e prioridade são utilizados por frontends como o dselect quando eles ordenam e selecionam os pacotes padrão. Assim que você enviar o pacote para o Debian, o valor dessas duas lacunas poderá ser alterada pelos mantenedores do repositório, caso o qual você será notificado por email.

Como este pacote é de prioridade normal e não entra em conflito com nada, nós deixaremos a lacuna preenchida como 'optional'.

A linha 4 é o nome e endereço de email do mantenedor. Certifique-se que este campo contenha um cabeçalho 'To:' válido para um email, porque depois que você enviar o pacote, o sistema de procura de bugs utilizará ele para enviar emails de bugs para você. evite utilizar vírgulas, '&'s e parênteses.

A 5ª linha contém a lista dos pacotes necessários para construir o seu pacote. Alguns pacotes, como o gcc e o make são implícitos, veja o pacote build-essential para detalhes. Se algum compilador ou ferramenta não-padrão for necessária para construir o seu pacote, você deve adicioná-lo à linha 'Build-Depends'. Múltiplas entradas são separadas por vírgulas; leia a seguir para uma explicação das dependências binárias para saber mais sobre a sintaxe deste campo.

Você também pode ter Build-depends-Indep, Build-Conflicts e outros campos aqui. Estas informações serão utilizadas pelo software de criação automática de pacotes do Debian para criar os pacotes binários para outras plataformas de computadores. Veja o Debian-Policy para mais informações sobre as dependências de compilação e a Referência do Desenvolvedor para mais informações sobre outras plataformas (arquiteturas) e como portar software para elas.

Eis um hack que você pode utilizar para descobrir quais pacotes o seu pacotes precisa para ser compilado:

       strace -f -o /tmp/log ./configure
       # or make instead of ./configure, if the package doesn't use autoconf
       for x in `dpkg -S $(grep open /tmp/log|\
                           perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
                           grep "^/"| sort | uniq|\
                           grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
                           cut -f1 -d":"| sort | uniq`; \
             do \
               echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
             done

O gentoo precisa dos pacotes xlibs-dev,libgtk1.2-dev e libglib1.2-dev para ser compilado, portanto vamos adiciona-los após o pacote debhelper.

A linha 6 é a versão do padrão do Debian-Policy que este pacote segue. As verões do Debian-Policy que você lê enquanto cria seu pacote.

A linha 8 é o nome do seu pacote binário. Isto normalmente é a mesma coisa que o nome do pacote-fonte, mas não precisa ser necessariamente desta forma.

A linha 9 descreve as arquiteturas de CPU para que o pacote binário pode ser compilado. Nós deixaremos este como 'any' pois dpkg-gencontrol(1) preencherá este campo com o valor adequado para qualquer máquina em que este pacote seja compilado.

Se o seu pacote é independente de arquitetura (por exemplo, um script shell ou Perl, ou um documento), mude este para 'all', e leia mais tarde em O arquivo `rules', Seção 4.4 sobre a utilização da regra 'binary-indep' ao invés da 'binary-arch' para construir o pacote.

A linha 10 mostra uma das funcionalidades mais poderosas do sistema de empacotamento do Debian. Os pacotes podem relacionar-se uns com os outros de várias formas. Além da 'Depends:', outros campos relacionais são 'Recommends:', 'Suggests:', 'Pre-Depends:', 'Conflicts:', 'Provides:', e 'Replaces:'.

As ferramentas de manutenção de pacotes normalmente se comportam da mesma maneira quando lidando com essas relações; se não, será explicado. (veja dpkg(8), dselect(8), apt(8), aptitude(1) etc.)

Eis o que as dependencias significam:

Todos estes campos tem uma sintaxe uniforme. Eles são uma lista de nomes de pacotes separados por vírgulas. Estes nomes de pacotes podem inclusive ser listas de nomes de pacotes alternativos, serados por simbolos de pipe (barras verticais '|).

Os campos podem restringir sua aplicabilidade a versões particulares de cada pacote listado. Essas versões são listadas entre parênteses após cada nome de pacote individualmente, e devem conter uma relação da seguinte lista seguida pelo número da versão. As relações permitidas são: <<, <=, =, >= e >> para anterior, anterior ou igual, exatamente igual, mais nova ou igual e igual, respectivamente. Por exemplo,

       Depends: foo (>= 1.2), libbar1 (= 1.3.4)
       Conflicts: baz
       Recommends: libbaz4 (>> 4.0.7)
       Suggests: quux
       Replaces: quux (<< 5), quux-foo (<= 7.6)

Finalmente, a última funcionalidade que você precisa saber é ${shlibs:Depends}. Depois que seu pacote for compilado e instalado no diretório temporário, dh_shlibdeps(1) irá procurar por binários e bibliotecas nesse diretório, determinar as dependências de bibliotecas compartilhadas e detectar em quais pacotes elas estão, como libc6 ou xlib6g. Ele irá passar a lista para o dh_gencontrol(1) que irá preencher o campo adequadamente, e você não terá de se precupar mais com isso.

Dito tudo isto, podemos deixar a linha 'Depends:' exatamente como ela está agora, e inserir outra linha após ela com Suggests: file, pois o gentoo pode utilizar algumas funcionalidade fornecidas por este programa/pacote.

A linha 11 é uma breve descrição. A maioria das telas das pessoas são de 80 colunas de largura, então esta descrição não deve ser maior que 60 caracteres. Eu mudarei este campo para "mantenedor de arquivos com interface completamente configurável para X utilizando GTK+".

A linha 12 é onde a descrição detalhada entra. Este deve ser um parágrafo que fornece maiores informações sobre o pacote. A coluna 1 de cada linha deve estar vazia. Não podem haver linhas em branco, mas você pode colocar um único '.' (ponto) numa coluna para simular isto. Além disso, não pode haver mais de uma linha em branco após a descrição detalhada.

Finalmente, eis o arquivo de controle atualizado:

       1  Source: gentoo
       2  Section: x11
       3  Priority: optional
       4  Maintainer: Josip Rodin <joy-mg@debian.org>
       5  Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
       6  Standards-Version: 3.5.2
       7
       8  Package: gentoo
       9  Architecture: any
       10 Depends: ${shlibs:Depends}
       11 Suggests: file
       12 Description: mantenedor de arquivos com interface completamente configurável para X utilizando GTK+
       13  o gentoo é um mantenedor de arquivos para Linux escrito totalmente em C puro. Ele
       14  utiliza o toolkit GTK+ para todas as suas necessidades de interface. O gentoo fornece
       15  uma interface 100% configurável; sem necessidade de editar arquivos de configuração manualmente ou
       16  reiniciar o programa. O gentoo suporta a identificação do tipo de vários
       17  arquivos (utilizando extensão, expressões regulares, ou o comando 'file'),
       18  e pode exibir arquivos de diferentes tipos com diferentes cores e ícones.
       19  .
       20  O gentoo adota alguns temas do clássico mantenedor de arquivos do Amiga
       21  "Directory OPUS" (escrito por Jonathan Potter).

(Eu adicionei os números das linhas.)


4.2 O arquivo `copyright'

Este arquivo contém informação sobre os recursos superiores do pacote, informações de copyright e licença. Seu formato não é tratado no Debian-Policy, mas seu conteúdo é (seção 13.6 "Informações de Copyright").

O dh_make criou o seguinte arquivo padrão:

       1  This package was debianized by Josip Rodin <joy-mg@debian.org> on
       2  Wed, 11 Nov 1998 21:02:14 +0100.
       3
       4  It was downloaded from <fill in ftp site>
       5
       6  Upstream Author(s): <put author(s) name and email here>
       7
       8  Copyright:
       9
       10 <Must follow here>

(Eu coloquei os números das linhas)

As coisas importantes a serem adicionadas a este arquivo são o lugar de onde você pegou o pacote, as informações de copyright e a licença do pacote. Você deve incluir a licença completa, a menos que seja um software livre de licença comum, como GNU GPL ou LPL, ou a licença artística do BSD, onde você pode simplesmente fazer referência à licença adequada ao diretório /usr/share/common-licenses/ que existe em todo sistema Debian.

Eis como o arquivo de copyright do gentoo ficaria:

       1  This package was debianized by Josip Rodin <joy-mg@debian.org> on
       2  Wed, 11 Nov 1998 21:02:14 +0100.
       3
       4  It was downloaded from: ftp://ftp.obsession.se/gentoo/
       5
       6  Upstream author: Emil Brink <emil@obsession.se>
       7
       8  Este software é copyright (c) 1998-99 por Emil Brink, Obsession
       9  Development.
       10
       11 Você é livre para distribuir este software sob os termos da
       12 GNU General Public License.
       13 Em sistemas Debian, o texto completo da GNU General Public
       14 License pode ser encontrado em '/usr/share/common-licenses/GPL'

(Eu adicionei os números das linhas.)


4.3 O arquivo `changelog'

Este arquivo é necessário, e tem um formato especial descrito no Debian-Policy seção 4.4 'debian/changelog'. Este formato é utilizado pelo dpkg e outros programas para obter o número da versão, revisão, distribuição e urgência do seu pacote.

Para você, também é importante, desde que é bom ter documentadas todas as mudanças que você fez. Este arquivo ajudará as pessoas que baixam o seu pacote a ver se existem questões sobre o pacote que eles devam saber. Ele será salvo como `/usr/share/doc/gentoo/changelog.Debian.gz' no pacote binário.

O dh_make criou o seguinte arquivo padrão:

       1  gentoo (0.9.12-1) unstable; urgency=low
       2
       3   * Initial Release.
       4
       5  -- Josip Rodin <joy-mg@debian.org>  Wed, 11 Nov 1998 21:02:14 +0100
       6

(Eu adicionei os números das linhas.)

A linha 1 é o nome do pacote, versão, distribuição e urgência. O nome deve ser o mesmo nome do pacote-fonte, a distribuição pode ser ou 'unstable' (ou até mesmo 'experimental'), e a urgência não deve ser mudada para nada acima de 'low'. :-)

As linhas 3-5 são a entrada de log, onde você deve documentar as mudanças feitas nessa revisão do pacote (não as mudanças superiores - existe um arquivo especial para este propósito, criado pelos autores, que você instalará depois em /usr/share/doc/gentoo/changelog.gz). Novas linhas devem ser inseridas logo antes da linha mais alta que começa com um asterisco ('*'). Você pode faze-lo com o dch(1), ou manualmente com um editor de texto.

Você terá algo como isso, no final das contas: You will end up with something like this:

       1  gentoo (0.9.12-1) unstable; urgency=low
       2
       3   * Initial Release.
       4   * Este é o meu primeiro pacote Debian.
       5   * Ajustado o Makefile para corrigir problemas de $DESTDIR.
       6
       7  -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100
       8

(Eu inseri os números das linhas.)

Você pode ler mais sobre a atualização do arquivo de changelog mais tard em Atualizando o pacote, Capítulo 9.


4.4 O arquivo `rules'

Nós precisamos dar uma olhada nas regras exatas que o dpkg-buildpackage(1) irá seguir para criar efetivamente o pacote. Este arquivo é, na verdade, outro Makefile, mas diferente do fornecido pelo autor do código-fonte. Diferentemente dos outros arquivos no debian, este arquivo tem de ser executável.

Todo arquivo 'rules', como qualquer outro Makefile, consiste em várias regras que especificam como tratar do código-fonte. Cada regra consistem em alvos, nomes de arquivos ou nomes de ações que devem ser seguidas (ex: 'build:' ou 'install:'). Regras que você quer que sejam invocadas como argumentos de linhas de comando (por exemplo, './debian/rules build' ou 'make -f rules install'). Depois do nome do alvo, você pode listar as dependências, programas ou arquivos de que a regra depende. Depois disso, podem haver quantos comandos forem necessários, indentados com <tab>. Uma nova regra começa com a declaração do alvo na primeira coluna. Linhas vazias e começadas com '#'s (hashs) são tratadas como comentários e são ignoradas.

Você provavelment está confuso agora, mas isso tudo ficará mais claro com a análiso do arquivo 'rules' que o dh_make nos dá como padrão. Você deve também ler a info do 'make' para maiores informações.

A parte importante de saber sobre o arquivo 'rules' criado pelo dh_make, é que ele é somente uma sugestão. Ele funcionará para pacotes simples, mas para os mais complicados, não tenha medo de adicionar ou retirar coisas para satisfazer às suas necessidades. A única coisa que não deve mudar são os nomes das regras, pois todas as ferramentas usam estes nomes, que são exigidos no Debian-Policy.

Eis (aproximadamente) como o debian/rules padrão que o dh_make gerou para nós é:

       1  #!/usr/bin/make -f
       2  # Sample debian/rules that uses debhelper.
       3  # GNU copyright 1997 to 1999 by Joey Hess.
       4
       5  # Uncomment this to turn on verbose mode.
       6  #export DH_VERBOSE=1
       7
       8  # This is the debhelper compatibility version to use.
       9  export DH_COMPAT=4
       10 
       11 CFLAGS = -g
       12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
       13 CFLAGS += -O0
       14 else
       15 CFLAGS += -O2
       16 endif
       17
       18 build: build-stamp
       19 build-stamp:
       20        dh_testdir
       21
       22        # Add here commands to compile the package.
       23        $(MAKE)
       24        #docbook-to-man debian/gentoo.sgml > gentoo.1
       25
       26        touch build-stamp
       27
       28 clean:
       29        dh_testdir
       30        dh_testroot
       31        rm -f build-stamp
       32
       33        # Add here commands to clean up after the build process.
       34        -$(MAKE) clean
       35
       36        dh_clean
       37
       38 install: build
       39        dh_testdir
       40        dh_testroot
       41        dh_clean -k
       42        dh_installdirs
       43
       44        # Add here commands to install the package into debian/gentoo.
       45        $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo
       46
       47 # Build architecture-independent files here.
       48 binary-indep: build install
       49 # We have nothing to do by default.
       50
       51 # Build architecture-dependent files here.
       52 binary-arch: build install
       53        dh_testdir
       54        dh_testroot
       55 #      dh_installdebconf
       56        dh_installdocs
       57        dh_installexamples
       58        dh_installmenu
       59 #      dh_installlogrotate
       60 #      dh_installemacsen
       61 #      dh_installpam
       62 #      dh_installmime
       63 #      dh_installinit
       64        dh_installcron
       65        dh_installman
       66        dh_installinfo
       67 #      dh_undocumented
       68        dh_installchangelogs ChangeLog
       69        dh_link
       70        dh_strip
       71        dh_compress
       72        dh_fixperms
       73 #      dh_makeshlibs
       74        dh_installdeb
       75 #      dh_perl
       76        dh_shlibdeps
       77        dh_gencontrol
       78        dh_md5sums
       79        dh_builddeb
       80
       81 binary: binary-indep binary-arch
       82 .PHONY: build clean binary-indep binary-arch binary install

(Eu adicionei os números das linhas.)

Você provavelmente já tem intimidade com linhas como a linha 1 de scripts shell e Perl. Ela diz ao sistema operacional que esse arquivo é para ser processado com o /usr/bin/make.

O significado das variáveis DH_* mencionadas nas linhas 6 e 9 deve ser evidente para a breve descrição. Para maiores informações sobre o DH_COMPAT leia a seção 'Níveis de compatibilidade do Debhelper' no manual debhelper(1).

As linhas 11-16 são o esqueleto do suporte para parâmetros do DEB_BUILD_OPTIONS, descritos no Debian-Policy seção 11.1 'Binários'. Basicamente, essas coisas controlam se os binários devem ser construídos com a tabela de símbolos, ou se eles devem ser retirados na instalação. Novamente, este é somente um esqueleto, uma dica de que você deve faze-lo. Você deve conferir como os sistemas de construçao superiores tratam da inclusão da tabela de símbolos e da sua retirada na instalação, ou implementar isso você mesmo.

Normalmente, você podedizer ao gcc para compilar com '-g' usando a variável CFLAGS -- se este é o caso do seu pacote, extenda a variável concatenando CFLAGS="$(CFLAGS)" à invocação do $(MAKE) na regra de construção (veja abaixo). Alternativamente, se o seu pacote usa um script de configuração do autoconf, você pode passá-lo concatenando antes do string acima na invocação do './configure' na regra de construção.

Para a remoção, os programas são normalmente configurados para se instalarem sem a remoção da tabela de símbolos, e normalmente sem uma opção para mudar isso. Felizmente, você ainda tem o dh_strip(1) que irá detectar quando o flag DEB_BUILD_OPTIONS=nostrip está definido e sair silenciosamente.

As linhas 18-26 descrevem a regra 'build' (e sua regra-filho 'build-stamp'), que executa o make com a o Makefile próprio do programa para compila-lo. Vamos falar sobre o comentado exemplo docbook-to-man mais tardem em manpage.1.ex, manpage.sgml.ex, Seção 5.8.

A regra 'clean', como especificado nas linhas 28-36, limpa qualquer binário não mais necessário ou coisas geradas automaticamente, deixadas após a construção do pacote. Esta regra deve funcionar todas as vezes (mesmo quando a árvore do código-fonte is cleaned up!), portanto use as opções para forçar (ex: para o rm, é '-f'), ou faça o make ignorar valores de retorno (falhas) utilizando um '-' na frente do nome do comando.

O processo de instalação , a regra 'install', começa na linha 38. Basicamente, ela executa a regra 'install' do Makefile do programa, mas instala ele no diretório $(CURDIR)/debian/gentoo - por isso especificamos $(DESTDIR) como a a raiz do diretório de instalação no Makefile do gentoo.

Como os comentários sugerem, a regra 'binary-indep', na linha 48, é usada para construir pacotes independentes de arquitetura. Como nós não temos nenhum, nada será feito aqui.

Na próxima regra - 'binary-arch', nas linhas 52-79, nas quais nós executamos muitos utilitários pequenos do pacote debhelper para executar várias operações nos arquivos do seu pacote para fazer o pacote concordante com o Debian-Policy.

Se o seu pacote é um 'Architecture: all', você precisa incluir todos os comandos para construir o pacote na regra 'binary-indep', e deixar a regra 'binary-arch' vazia.

Os nomes dos programas do debhelper começam com 'dh_', e o resto é a descrição do que o utilitário faz em particular. E bastante auto-explicativo, mas eis algumas explicações adicionais:

Para informações mais completas sobre o que todos esses scripts dh_* fazem, e quais são suas opções, por favor leia seus respectivos manuais. Existem alguns outros (possivelmente muito úteis) scripts dh_* que não são mencionados aqui. Se você precisar deles, leia a documentação do debhelper.

A seção binary-arch é onde você realmente deve comentar ou remover quaisquer linhas que chamem funcionalidades que você não precisa. Para o gentoo, eu comentarei as linhas sobre exemplos, cron, init, man e info, simplesmente porque o gentoo não precisa delas. Além disso, na linha 68, eu irei substituir 'Changelog' com 'FIXES', porque esse é o nome real do arquivo de changelog superior.

As últimas duas linhas (junto com quaisquer outras não explicadas) são somente algumas coisas mais ou menos necessárias, considerando que você pode ler o manual do make, e o Debian-Policy. Por enquanto, elas não são importantes de se conhecer.


[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ próximo ]

Guia do Novo Mantenedor Debian

version 1.2, 6 April 2002.

Josip Rodin joy-mg@debian.org
Traduzido por: Mahdi mahdi@dcc.ufmg.br
Revisado por: Priscilla Pimenta priscilla@minaslivre.org