Translation(s): English - ?Español - Italiano - Català - Português (Brasil) - Română - Русский
Contents
Introdução ao Empacotamento Debian
Este é um tutorial introdutório para fazer pacotes Debian: ele não vai muito fundo nas partes mais intrincadas do empacotamento Debian, mas mostrará como fazer pacotes Debian para softwares que são simples de empacotar.
O que é um "pacote"?
Um pacote Debian é uma coleção de arquivos que permite que aplicativos ou bibliotecas sejam distribuídos através do sistema de gerenciamento de pacotes. O objetivo do empacotamento é permitir a automação da instalação, atualização, configuração e remoção de programas de computador para o Debian de maneira consistente. Um pacote consiste em um pacote-fonte e um ou mais pacotes binários. A Política Debian (Debian Policy) especifica o formato padrão para um pacote, que todos os pacotes devem seguir.
Os pacotes binários contêm executáveis, arquivos de configuração padrão, outros recursos necessários para que os executáveis sejam executados, documentação, dados, ...
Os pacotes-fonte contêm a distribuição de código-fonte do(a) autor(a) original (upstream), configurações do sistema de construção do pacote, lista de dependências de tempo de execução e pacotes conflitantes, uma descrição legível por máquina de copyright e informações de licença, configurações iniciais do software, e muito mais.
O objetivo do empacotamento é produzir esses pacotes a partir da fonte não empacotada. O pacote-fonte (.dsc) e os pacotes binários (.deb) serão construídos para você por ferramentas como a dpkg-buildpackage.
Você pode ler mais sobre a anatomia de pacotes binários ou de pacotes-fonte em suas páginas wiki.
Os pacotes devem estar de acordo com a política Debian para serem aceitos nos repositórios de pacotes. Pacotes binários .deb construídos manualmente que não foram construídos a partir de um pacote-fonte não serão aceitos. Isso mantém a consistência e a reprodutibilidade.
Requisitos
Este tutorial presume que você entende:
- instalação de pacotes binários
- uso geral da linha de comando
- edição de arquivos usando um editor de texto de sua escolha
Isso é tudo o que você precisa.
Pacotes necessários:
debhelper versão 9 ou superior
Três conceitos centrais
Os três conceitos centrais são:
tarball upstream:
Um tarball é o arquivo .tar.gz ou .tgz criado pelo(a) upstream (também pode estar em outros formatos de compressão como .tar.bz2, .tb2 ou .tar.xz).
Contém o software que o(a) desenvolvedor(a) original upstream escreveu.
pacote-fonte:
Esta é a segunda etapa no processo de empacotamento, construir o pacote fonte a partir da fonte upstream.
'pacote binário' :
A partir desse pacote-fonte, você então constrói o pacote binário que é distribuído e instalado.
O pacote-fonte mais simples consiste em três arquivos:
- O arquivo tarball upstream, renomeado de acordo com a convenção de nomenclatura;
- Um diretório debian, contendo as mudanças feitas no código-fonte upstream, mais todos os arquivos necessários para a criação de um pacote binário.
Um arquivo de descrição (com extensão .dsc), que contém metadados para os dois arquivos acima.
O fluxo de trabalho do empacotamento
- Etapa 1: Renomear o arquivo tarball upstream
- Etapa 2: Descompactar o arquivo tarball upstream
- Etapa 3: Adicionar os arquivos debian.tar.gz
- Etapa 4: Construir o pacote
- Etapa 5: Testar o pacote
Após o teste, o pacote-fonte e binários podem ser carregados no repositório Debian.
Para este tutorial, este tarball será usado como exemplo.
Etapa 1: Renomear o arquivo tarball upstream
As ferramentas de empacotamento exigem que o arquivo tarball esteja em conformidade com a convenção de nomenclatura.
O nome deve ser: nome do pacote-fonte, sublinha, número da versão upstream seguido por .orig.tar.gz. O nome do pacote-fonte deve estar em letras minúsculas e pode conter letras, dígitos e traços. Outros caracteres também são permitidos. Convenções de nomenclatura mais detalhadas podem ser encontradas em debmake doc.
Mudanças mínimas devem ser feitas no nome original para torná-lo compatível com o Debian. Se o nome original estiver de acordo com o padrão, você deve usá-lo.
No nosso exemplo, a upstream escolheu um nome adequado, "hithere", portanto não há necessidade de alterações.
Terminaremos com um arquivo chamado hithere_1.0.orig.tar.gz.
Observe que há uma sublinha (_), não um traço (-), no nome. Isso é importante.
$ mv hithere-1.0.tar.gz hithere_1.0.orig.tar.gz
Etapa 2: Descompactar o arquivo tarball upstream
O código-fonte será descompactado em um diretório de mesmo nome e com a versão upstream com um hífen no meio (não uma sublinha). Desse modo, o tarball upstream de exemplo deve ser descompactado em um diretório chamado "hithere-1.0".
Nesse caso, o tarball já descompacta no subdiretório correto, portanto nenhuma alteração é necessária.
$ tar xf hithere_1.0.orig.tar.gz
Etapa 3: Adicionar os arquivos de empacotamento Debian
Todos os arquivos a seguir serão colocados no subdiretório debian/ dentro do diretório de origem, portanto criamos esse diretório.
$ cd hithere-1.0
$ mkdir debian
Vamos dar uma olhada nos arquivos que precisamos fornecer.
debian/changelog
O primeiro arquivo é o debian/changelog. Este é o registro (log) das mudanças no pacote Debian.
Não é necessário listar tudo o que foi alterado no código upstream, mas um resumo é útil para outras pessoas.
Como agora estamos fazendo a primeira versão, não há nada para registrar. No entanto, ainda assim precisamos fazer uma entrada no changelog porque as ferramentas de empacotamento lêem as informações do changelog: a mais importante, a versão do pacote.
debian/changelog tem um formato padrão. A maneira mais fácil de criá-lo é usando a ferramenta dch.
$ dch --create -v 1.0-1 -u low --package hithere
Isso resulta em um arquivo como este:
hithere (1.0-1) UNRELEASED; urgency=low * Initial release. (Closes: #XXXXXX) -- Lars Wirzenius <liw@liw.fi> Thu, 18 Nov 2010 17:25:32 +0000
Algumas notas:
O nome do pacote (hithere) DEVE ser igual ao nome do pacote-fonte. 1.0-1 é a versão. A parte 1.0 é a versão upstream. A parte -1 é a versão Debian: a primeira versão do pacote Debian da versão upstream 1.0. Se o pacote Debian tiver um bug e for corrigido, mas a versão upstream permanecer a mesma, a próxima versão do pacote será chamada 1.0-2. Depois 1.0-3, e assim por diante.
UNRELEASED é chamado de alvo do upload. Ele diz para onde o pacote binário deve ser enviado. UNRELEASED significa que o pacote ainda não está pronto para o upload. É uma boa ideia manter UNRELEASED lá para que não seja feito um envio por engano.
urgency=low não será explicado agora.
A parte (Closes: #XXXXXX) é para fechar bugs quando o pacote é carregado. Essa é a maneira usual de fechar bugs no Debian: quando o pacote que corrige o bug é enviado, o rastreador de bugs percebe e marca o bug como fechado. Se não houver bugs a serem corrigidos, esta parte pode ser omitida.
- A linha final do changelog diz quem construiu esta versão do pacote e quando. A ferramenta dch tenta adivinhar o nome e o endereço de e-mail, mas você pode configurá-lo com os detalhes corretos. Consulte a página de manual dch(1) para detalhes.
debian/control
O arquivo de controle descreve o pacote-fonte e o pacote binário, e fornece algumas informações sobre eles, como seus nomes, quem é o(a) mantenedor(a) do pacote e assim por diante. Aqui está um exemplo:
Source: hithere Maintainer: Lars Wirzenius <liw@liw.fi> Section: misc Priority: optional Standards-Version: 4.6.2 Build-Depends: debhelper-compat (= 13) Package: hithere Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: greet user hithere greets the user, or the world.
Existem vários campos obrigatórios, mas você pode apenas tratá-los como mágicos por enquanto. Portanto, em debian/control existem dois trechos de código.
O primeiro trecho descreve o pacote-fonte com estes campos:
- Source
- O nome do pacote-fonte.
- Maintainer
- O nome e endereço de e-mail da pessoa responsável pelo empacotamento.
- Priority
A prioridade do pacote (que pode ser 'required', 'important', 'standard' ou 'optional'). Em geral, um pacote é 'optional' a menos que seja 'essential' para um sistema funcional padrão, ou seja, inicializar ou acessar uma rede. De acordo com a Política Debian 4.5.1 (ou mais recente), a prioridade de pacote 'extra' está obsoleta.
- Build-Depends
- A lista de pacotes que precisam ser instalados para construir o pacote. Eles podem ou não ser necessários para realmente usar o pacote.
Todos os trechos de código após o primeiro descrevem os pacotes binários construídos a partir dessa fonte. Pode haver muitos pacotes binários construídos a partir de uma mesma fonte; nosso exemplo tem apenas um. Usamos estes campos:
A dependência de construção (Build-Dependency) debhelper-compat especifica o "nível de compatibilidade" para o nível da ferramenta debhelper via uma limitação de versão. O exemplo acima especifica a compatibilidade nível 13 (que substitui o arquivo obsoleto debian/compat).
- Package
- O nome do pacote binário. O nome pode ser diferente do nome do pacote-fonte.
- Architecture
- Especifica em quais arquiteturas de computador o pacote binário deve funcionar: i386 para CPUs Intel de 32 bits, amd64 para 64 bits, armel para processadores ARM, e assim por diante. O Debian funciona em cerca de uma dúzia de arquiteturas de computador no total, portanto este suporte de arquiteturas é crucial. O campo "Architecture" pode conter nomes de arquiteturas específicas, mas geralmente contém um de dois valores especiais.
- any
- (que vemos no exemplo) significa que o pacote pode ser construído para qualquer arquitetura. Em outras palavras, o código foi escrito para ser portável, portanto não faz muitas suposições sobre o hardware. No entanto, o pacote binário ainda precisará ser construído para cada arquitetura separadamente.
- all
- significa que o mesmo pacote binário funcionará em todas as arquiteturas sem ter que ser construído separadamente para cada uma. Por exemplo, um pacote que consiste apenas em scripts shell seria "all". Os scripts shell funcionam da mesma forma em qualquer lugar e não precisam ser compilados.
- Depends
A lista de pacotes que devem ser instalados para o programa no pacote binário funcionar. Listar essas dependências manualmente é um trabalho tedioso e sujeito a erros. Para fazer isso funcionar de forma mais automática, o pedaço mágico ${shlibs:Depends} precisa estar lá para pacotes que contém bibliotecas compartilhadas construídas e executáveis. Outra coisa mágica está lá para o debhelper, o que completa o ${misc:Depends}. Para outras dependências, você precisará adicioná-las manualmente em Depends ou Build-Depends e a parte mágica ${...} somente funciona em Depends. Note que os pedaços mágicos ${...} somente funcionam em Depends, mas não em Build-Depends.
- Description
- A descrição completa do pacote binário. Destina-se a ser útil para usuários(as). A primeira linha é usada como uma breve descrição da sinopse (resumo) e o resto da descrição deve ser uma descrição independente mais longa do pacote.
O comando cme edit dpkg fornece uma interface gráfica para editar a maioria dos arquivos de empacotamento, incluindo debian/control. Consulte a página Gerenciando pacotes Debian com cme. O comando cme é distribuído no Debian no pacote cme. Você também pode editar apenas o arquivo debian/control com o comando cme edit dpkg-control.
debian/copyright
É um arquivo muito importante, mas por agora ficaremos felizes com um arquivo vazio.
Para o Debian, esse arquivo é usado para controlar as informações legais relacionadas a direitos autorais sobre um pacote. No entanto, não é importante do ponto de vista técnico. Por enquanto, vamos nos concentrar nos aspectos técnicos. Voltaremos ao debian/copyright mais tarde, se houver interesse.
debian/rules
Ele deve se parecer com isto:
#!/usr/bin/make -f %: dh $@
Nota: a última linha deve ser identada por um caractere TAB, não por espaços. É um arquivo makefile e o TAB é o que o comando make deseja.
debian/rules pode se tornar um arquivo bastante complicado. No entanto, o comando dh no debhelper versão 7 tornou possível mantê-lo simples em muitos casos.
debian/source/format
O arquivo final que precisamos é debian/source/format, que deve conter o número da versão para o formato do pacote-fonte, que é "3.0 (quilt)".
3.0 (quilt)
Etapa 4: Construir o pacote
Primeira tentativa
Agora podemos construir o pacote.
Existem muitos comandos que podemos usar, mas este é o que usaremos. Se executar o comando, obterá uma saída semelhante a esta:
$ debuild -us -uc
make[1]: Entering directory `/home/liw/debian-packaging-tutorial/x/hithere-1.0'
install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin
install: cannot create regular file `/home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/liw/debian-packaging-tutorial/x/hithere-1.0'
dh_auto_install: make -j1 install DESTDIR=/home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere returned exit code 2
make: *** [binary] Error 29
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1325:
dpkg-buildpackage -rfakeroot -D -us -uc failed
Algo deu errado. Isso é o que geralmente acontece. Você faz o seu melhor criando os arquivos debian/*, mas sempre há algo que você não acerta.
O que deu errado é esta parte:
install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/local/bin
O Makefile upstream está tentando instalar o programa compilado no local errado.
Há algumas coisas acontecendo aqui: a primeira é sobre como funciona o empacotamento Debian.
Correção
Quando o programa foi compilado e "instalado", ele não é instalado em /usr ou /usr/local como de costume, mas em algum lugar sob o subdiretório debian/.
Nós criamos um subconjunto de todo o sistema de arquivos em debian/hithere e a seguir o colocamos no pacote binário. Portanto, a parte .../debian/hithere/usr/local/bin está boa, exceto que não deveria ser instalada em usr/local, mas diretamente sob usr.
Precisamos fazer algo para que ele seja instalado no local correto (debian/hithere/usr/bin).
A maneira certa de consertar isso é mudar debian/rules para que diga ao Makefile onde instalar as coisas.
#!/usr/bin/make -f %: dh $@ override_dh_auto_install: $(MAKE) DESTDIR=$$(pwd)/debian/hithere prefix=/usr install
É novamente um pouco de mágica, e para entendê-la você precisará saber como os Makefiles funcionam e os vários estágios de uma execução do debhelper.
Por enquanto vou resumir dizendo que existe um comando que o debhelper executa que se encarrega de instalar os arquivos upstream, e este estágio é chamado de dh_auto_install.
Precisamos sobrescrever este estágio, e fazemos isso com uma regra em debian/rules chamada override_dh_auto_install.
A linha final no novo debian/rules é um pouco da tecnologia dos anos 1970 para invocar o Makefile upstream do debian/ rules com os argumentos corretos.
Vamos tentar novamente
$ debuild -us -uc
Ainda falha!
- Desta vez, este é o comando com erro:
install hithere /home/liw/debian-packaging-tutorial/x/hithere-1.0/debian/hithere/usr/bin
Agora estamos tentando instalar no lugar certo, mas ele não existe. Para corrigi-lo, precisamos informar as ferramentas de empacotamento para primeiro criar o diretório.
Idealmente, o Makefile upstream criaria o próprio diretório, mas, neste caso, o(a) desenvolvedor(a) upstream estava com preguiça de fazê-lo.
Outra correção
As ferramentas de empacotamento (especificamente a debhelper) fornecem uma maneira de fazer isso.
Crie um arquivo chamado debian/hithere.dirs e faça com que tenha a seguinte aparência:
usr/bin usr/share/man/man1
A segunda linha cria o diretório para a página do manual. Vamos precisar disso mais tarde. Você deve ter cuidado ao manter esses arquivos *.dirs porque isso pode levar a diretórios vazios em versões futuras do seu pacote se os itens listados nesses arquivos não forem mais válidos.
Vamos tentar mais uma vez
$ debuild -us -uc
Agora a construção é bem-sucedida, mas ainda há alguns pequenos problemas.
O debuild executa a ferramenta lintian, que verifica o pacote que foi compilado em busca de alguns erros comuns. Ele relata vários problemas para este novo pacote:
Now running lintian...
W: hithere source: out-of-date-standards-version 3.9.0 (current is 3.9.1)
W: hithere: copyright-without-copyright-notice
W: hithere: new-package-should-close-itp-bug
W: hithere: wrong-bug-number-in-closes l3:#XXXXXX
Finished running lintian.
Esses erros eventualmente devem ser consertados, mas nenhum deles parece que será um problema para testar o pacote. Portanto, vamos ignorá-los por enquanto.
Procure no diretório superior o pacote que foi compilado.
$ ls ..
hithere-1.0 hithere_1.0-1_amd64.deb hithere_1.0.orig.tar.gz
hithere_1.0-1_amd64.build hithere_1.0-1.debian.tar.gz
hithere_1.0-1_amd64.changes hithere_1.0-1.dsc
Etapa 5: Instalar o pacote
O comando a seguir instalará o pacote que você acabou de criar.
NÃO execute-o em um computador, a menos que você não se importe de quebrá-lo.
- Em geral, é melhor fazer o desenvolvimento do pacote em um computador que tenha um bom backup e que você não se importe de reinstalar se tudo der muito errado.
Máquinas virtuais são um bom lugar para fazer desenvolvimento.
$ sudo dpkg -i ../hithere_1.0-1_amd64.deb
[sudo] password for liw:
Selecting previously deselected package hithere.
(Reading database ... 154793 files and directories currently installed.)
Unpacking hithere (from ../hithere_1.0-1_amd64.deb) ...
Setting up hithere (1.0-1) ...
Processing triggers for man-db ...
liw@havelock$
Como testamos o pacote? Podemos executar o comando:
$ hithere
Ele funciona!
Mas não está perfeito. Lembre-se, o lintian tinha coisas a dizer, o arquivo debian/copyright está vazio, etc.
Temos um pacote que funciona, mas ainda não tem a alta qualidade que se espera de um pacote Debian.
Conclusão
Depois de construir seus próprios pacotes, você eventualmente vai querer aprender como configurar seu repositório apt para que seu pacote seja fácil de instalar. A melhor ferramenta que conheço para isso é o reprepro.
Para mais testes de seu pacote, dê uma olhada na ferramenta chamada piuparts (eu o escrevi originalmente, então é perfeito e nunca tem nenhum bug. er...)
E, finalmente, se começar a fazer alterações no arquivo-fonte original upstream, você vai querer aprender sobre a ferramenta quilt.
Outras coisas que você pode querer ler estão listadas na página da web https://www.debian.org/devel/.
Perguntas e respostas
PERGUNTA: Por favor, esclareça sobre como empacotar softwares que já estão na forma binária, ou seja, blob nvidia ou similares.
RESPOSTA: Para pacotes de blob binários, você trata o tarball com os blobs como pacote-fonte e apenas evita compilá-los a partir do código-fonte; no entanto, eu nunca tive que fazer isso.
PERGUNTA: existe algo como PPA do Ubuntu?
RESPOSTA: O Debian não executa um serviço PPA como o Ubuntu, mas todas as ferramentas para fazer repositórios apt estão lá, é apenas um monte de coisa para configurar sozinho(a).
PERGUNTA: precisamos empacotar novamente o tarball original se ele não contiver uma pasta foo-1.0 com o nome adequado?
RESPOSTA: Acho que hoje em dia você não precisa reempacotar. Costumava ser necessário muitos, muitos anos atrás, mas agora o comando "dpkg-source -x" nomeará o diretório da maneira correta se necessário.
PERGUNTA: Eu vejo pacotes DEB "oficiais" em /var/cache/apt/archives sem arquivos changelog. Por quê?
RESPOSTA: Os pacotes .deb em /var/cache/apt/archives são pacotes binários; o changelog está incluído neles (com um nome diferente).
PERGUNTA: Eu ouvi falar de um formato específico de não mantenedor(a) para números de revisão Debian.
RESPOSTA: Acho que você quer dizer o formato de "pacote nativo" ("native" - em que o número da versão seria apenas 1.0, não 1.0-1); ou o formato de "non-maintainer upload", caso em que seriam muitos detalhes para esta sessão, mas "1.0-1.1" seria um exemplo
PERGUNTA: Quando "dpkg-source -x" é executado? Isso é feito manualmente?
RESPOSTA: "dpkg-source -x" é o comando para descompactar um pacote-fonte Debian após ele já ter sido compilado (normalmente por outra pessoa); normalmente não é executado ao criar o pacote.
PERGUNTA: Como alguém pode determinar os pacotes necessários para serem usados pelo Build-Depends?
RESPOSTA: Normalmente faço isso por a) tentativa e erro e b) lendo o código-fonte do programa. Ambos são geralmente necessários.
PERGUNTA: Posso construir um pacote para armel a partir do meu i386, e posso fazê-lo facilmente?
RESPOSTA: Isso seria uma compilação cruzada e não acho que haja uma maneira fácil de fazer isso; existem ferramentas para isso, mas não estou familiarizado com elas, desculpe.
PERGUNTA: Qual é a diferença entre Depends e Build Depends, em que caso eu tenho que usar apenas Depends em vez de Build-Depends?
RESPOSTA: Build-Depends são necessários apenas durante a construção do pacote, enquanto está sendo compilado e seu conjunto de testes está sendo executado. Depends é necessário apenas quando o pacote está realmente sendo usado, após ser instalado. Algumas coisas podem ser dependências de construção e de tempo de execução e, nesse caso, você precisa colocá-las em Build-Depends e Depends.
Por exemplo, se um pacote contém um script PHP, mas não é executado enquanto o pacote é compilado, o PHP entraria apenas em Depends, não em Build-Depends.
No entanto, se o script PHP for usado apenas para executar um teste e não for incluído no pacote binário, seria apenas em Build-Depends e não em Depends.
PERGUNTA: Posso ter um Build-Depends que não tenha um Depends correspondente? Estou pensando em bibliotecas vinculadas estáticas.
RESPOSTA: Build-Depends e Depends são totalmente separados e está perfeitamente ok (do ponto de vista da ferramenta de empacotamento) ter dependências apenas em um e não no outro, ou em ambos.
PERGUNTA: Se eu quiser fazer um NMU, devo escrever meu nome no campo Uploader, no campo Maintainer, nenhum?
RESPOSTA: (por dapal) Em nenhum, mas a primeira linha do changelog deve ser "Non-maintainer upload".
PERGUNTA: Quando eu construo um pacote com o campo "Architecture: all", alguns dos arquivos resultantes (b.build, .changes) ainda têm a arquitetura de construção no nome. É um comportamento correto?
RESPOSTA: Sim, esse é o comportamento correto, não precisa se preocupar com isso.
PERGUNTA: Existe outro pacote para o pacote-fonte ou é igual ao pacote binário? Vou gerar e manter dois pacotes (binário e fonte)?
RESPOSTA: Você edita o pacote-fonte e, em seguida, executa um comando (que abordarei em breve) para construir o pacote binário a partir do pacote-fonte.
PERGUNTA: Não está claro para mim se as opções de "Architecture" farão efeito sobre o pacote-fonte (processo de construção) ou sobre o pacote binário (instalar e executar).
RESPOSTA: O campo "Architecture:" diz a quem está construindo o pacote se há algum motivo em construir o pacote em uma arquitetura de computador específica. Desse modo, se disser apenas i386, não há por que construí-lo para AMD64.
PERGUNTA: Aquele exemplo do debian/rules contém apenas #!make -f , o que fazer com ./configure, ou cmake, ou scons ou... qualquer outra parte?
RESPOSTA: O dh tem muita heurística, então um pacote com um script ./configure, ou com uma das outras formas comuns de construção de pacotes, geralmente será construído sem quaisquer adições.
PERGUNTA: A heurística é boa, mas e se precisarmos passar --with-something-special como argumentos para o configure ou para o cmake, a heurística lida com os pacotes-fonte que precisam de ./waf e outras ferramentas para construir?
RESPOSTA: Gosto da resposta do(a) dapal: <dapal> lilith: usando dh7, se quiser passar algo para ./configure, apenas faça algo como: override_dh_auto_configure <TAB> dh_auto_configure - --seus-parâmetros
dh tem uma boa extensão/sobrescrita (override) de mecanismos que permite a você anular partes específicas; é muito fácil de usar depois de ler a documentação
<aron> Tive algumas experiências ruins com software de empacotamento que usa waf como sistema de construção. Geralmente contém blob binário que não pode ser extraído por ferramentas padrão (sim, ele incorpora um tgz no script), e o que é crítico, é difícil manter seu pacote Debian com um sistema de construção waf porque não se destina a ajudar o(a) upstream a construir seus pacotes de uma forma mais padronizada, mas apenas funciona para mim. Você realmente deve sugerir que seu(sua) upstream considere outro (alguns poderosos como CMake, Autotools; ou mais simples como python-distutils-extra), se possível.
PERGUNTA: Onde podemos encontrar documentos sobre override do debhelper 9?
RESPOSTA: O dh executa uma sequência específica de comandos para construir um pacote; cada comando é denominado dh_algumacoisa, e cada um desses comandos pode ser sobrescrito com uma entrada debian/rules chamada override_dh_algumacoisa.
Adicione a opção --no-act ao comando dh em debian/rules para ver quais comandos ele executa; você então tem que ler a página de manual desse comando para ver se pode configurá-lo (através de um arquivo, como o debian/hithere.dirs), ou se você precisa sobrepô-lo (overrride). Na prática, usar a opção --no-act em combinação com --verbose permitirá que você saiba mais detalhes sobre o que seria executado.
PERGUNTA: De onde você costuma executar seus comandos? Dentro do diretório hithere-1.0 ou fora? Deve haver um diretório externo chamado hithere (sem número)?
RESPOSTA: Eu sempre executo os comandos de empacotamento no diretório hithere-1.0 e geralmente tenho um diretório acima daquele chamado hithere, mas esse diretório superior não é necessário, é apenas mais organizado para que arquivos de projetos diferentes não se misturem.
PERGUNTA: Eu tenho um(a) upstream que precisa de um qmake (usa Qt) antes do make. Posso adicioná-lo ao debian/rules? Como?
RESPOSTA: (por gregoa) O debhelper suporta qmake desde 7.4.12 (portanto, não é necessário nada mais). Antes disso, você precisava de um override_dh_auto_configure :\n\tqmake.
PERGUNTA: Qual é um bom fluxo de trabalho para atualizar um pacote para uma nova versão upstream?
RESPOSTA: Ah, não tenho certeza qual é o melhor fluxo de trabalho para isso, mas basicamente: descompacte o código-fonte upstream em um novo diretório, copie o diretório debian/* do pacote antigo, atualize o debian/changelog ("dch -v 1.2.3-4") e tente construir e consertar qualquer coisa que esteja quebrada. Este não é um fluxo de trabalho muito bom, mas para isso você precisará aprender quilt e, possivelmente, como usar o gerenciamento de versão com o pacote debian, e esse é um tópico muito grande para esta sessão, desculpe.
PERGUNTA: Eu fiz um pacote debian que depende de vários outros pacotes. A única coisa que meu pacote faz é configurar os outros pacotes de uma certa maneira que atenda às necessidades de certas pessoas. Para isso, também faz algumas mudanças críticas do sistema, como ativar o roteamento de rede no kernel e assim por diante. Existe algo como uma regra sobre o que um pacote oficial pode fazer ou não? Esse pacote pode ser um pacote oficial?
RESPOSTA: https://www.debian.org/doc/debian-policy/ é o melhor conjunto de regras escrito que temos sobre o que um pacote Debian oficial tem permissão ou é obrigado a fazer.
Os pacotes Debian não têm permissão para alterar as configurações de outro pacote, a menos que o pacote forneça uma interface documentada para ele.
Veja também
Packaging é a página que reúne tudo sobre empacotamento neste wiki