FAQ empacotamento Debian

De Eriberto Wiki
Ir para navegação Ir para pesquisar


Este FAQ é um complemento para a página Algumas coisas sobre Debian..., disponível em http://debianet.com.br.

Esta página também poderá ser acessada pelo endereço http://eriberto.pro.br/debian/faq.html.


Dúvidas iniciais

Preciso ser programador para empacotar no Debian?

Em resumo, NÃO!

Você precisa conhecer Debian, um pouquinho de shell script (bem básico), além de saber compilar e instalar programas. No fim, você disponibilizará executáveis prontos para usuários finais, dentro de um arquivo .deb, que é um arquivo compactado com 'ar'. Como experiência, você pode executar um '$ ar -x pacote.deb' para ver o seu conteúdo.

Programar ajuda a sanar determinados problemas e fazer melhorias além do básico. No entanto, não ser programador não impede ninguém de ser empacotador. Várias pessoas que mantêm pacotes no Debian não são programadores.

Onde posso aprender a empacotar?

A documentação oficial é o Guia dos Novos Mantenedores, disponível em https://www.debian.org/devel (em HTML). Ele também está disponível em outros formatos e idiomas aqui.

Para quem fala português, há videoaulas disponíveis em http://debianet.com.br.

Outra possibilidade interessante é de inscrever-se na lista Debian Mentors, destinada a retirar dúvidas de quem empacota ou está começando e acompanhá-la.

Obtenção de um sponsor

O que é um sponsor?

É um desenvolvedor Debian (DD) que, voluntariamente, poderá analisar o seu pacote e fazer upload do mesmo para o Debian, uma vez que somente membros oficiais podem fazer upload.

Para onde envio o meu pacote quando estiver pronto?

  • Inicialmente, crie uma conta no site http://mentors.debian.net.
  • Você também vai precisar de uma chave GPG RSA de 4096 bits. Para isso siga as instruções existentes em https://wiki.debian.org/Keysigning. Siga os passos 1 a 7 COM ATENÇÃO.
  • Envie o seu pacote para o mentors, usando o comando dput mentors. Instruções aqui.
  • A seguir, busque por um sponsor. O sponsor é um Debian Developer (Desenvolvedor Debian, ou DD) que fará o upload do seu pacote para o Debian. Você poderá encontrar um no mundo (mais sponsors disponíveis) ou no Brasil. Veja como:
    • No mundo: crie um bug para o pacote virtual sponsorship-requests. Siga fielmente as instruções que estão aqui. Note que o próprio site mentors criará um template para você usar para o seu RFS (Request For Sponsor). Basta entrar na página que mostra o pacote do qual foi feito upload e procurar por View RFS template.
    • No Brasil: inscreva-se na lista Debian Devel Portuguese. A seguir, envie um email solicitando que alguém revise o seu pacote, dizendo o nome, o que ele faz e o endereço no mentors.

Obs: todos os DDs estão cadastrados aqui.

Há condições mínimas que que eu solicite um sponsor?

Sim. Um sponsor trabalha de forma voluntária, dedicando o seu tempo, sem receber nada por isso. Então:

  • Não envie pacotes mal feitos ou cheios de mensagens de lintian que podem ser sanadas. O seu pacote será sumariamente ignorado.
  • Não envie várias mensagens seguidas pedindo um sponsor. Por se tratar de um trabalho voluntário, você deve esperar pela disponibilidade de alguém. Você poderá enviar uma nova mensagem depois de muito tempo (um mês é uma boa medida). Mas, normalmente, os pedidos são atendidos rapidamente.
  • Seja sempre cordial com quem está dedicando tempo para lhe ajudar.
  • Se for o caso, antes de enviar um pacote, retire todas as suas dúvidas nos canais destinados a isso. Veja o item Onde posso obter ajuda, retirar dúvidas sobre empacotamento?

Progresso do empacotamento

Como o meu pacote e o meu nome serão mostrados no Debian?

Vamos às possibilidades:

  • Depois que um DD fizer o upload para você, o pacote com o seu nome poderá ser visto em https://tracker.debian.org. Cabe ressaltar que no exato momento do upload, ele ficará por cerca de 5 minutos aqui.
  • Após o seu primeiro upload, o seu nome será registrado aqui. Pode demorar até 1 mês para o seu nome aparecer.
  • O seu último upload sempre aparecerá aqui. Essa lista é atualizada a cada mês.
  • O seu nome também será mostrado neste rancking.
  • Se o seu pacote for novo no Debian, no dia seguinte à aprovação o nome dele aparecerá aqui.
  • Após algum tempo, o seu pacote também aparecerá aqui.
  • Se você for dono de pacotes, verá o seu nome aqui também.
  • No momento em que o pacote entrar no unstable ou na experimental, ele será mostrado na lista debian-devel-changes.

Quando você tiver um pacote, será criada uma página específica para você, cujo endereço será https://qa.debian.org/developer.php?login=<seu email>. Clique aqui para ver a minha página como exemplo.

Onde posso obter ajuda, retirar dúvidas sobre empacotamento?

Há várias opções para você poder retirar as suas dúvidas on-line.

  • Lista Debian Mentors: esta é uma lista internacional, destinada especificamente à retirada de dúvidas sobre empacotamento.
  • Canal #debian-mentors no IRC irc.debian.org, porta 9999 (com SSL) ou 7000 (sem SSL, também podendo ser 6667). Este é um canal IRC análogo à lista Debian Mentors.
  • Lista Debian Devel Portuguese, para quem quiser suporte em português.
  • Também há o canal #debian-devel-br, no mesmo IRC citado anteriormente.

Enviei um pacote para o Debian. Eu sou DM? Como ser DD?

Não, você não é um DM (Debian Maintainer).

Quem mantém pacotes no Debian é um mantenedor de pacotes ou empacotador. Existe uma classe, um pouco acima, que exige um pouco mais de experiência, chamada Debian Maintainer (DM). Para se tornar um DM, você precisará realizar alguns procedimentos básicos. Após algum tempo, você poderá fazer algumas provas de certificação, dentro do Debian, e se tornar um Debian Developer (DD).

Para entender tudo isso, assista a essa palestra, com 50 minutos de duração.

O meu pacote é inédito no Debian e foi para a NEW. Quanto tempo ficará lá?

A fila NEW é destinada a pacotes que estão nas seguintes situações:

  • Entrando pela primeira vez no Debian. O pacote irá para essa fila mesmo tendo passado pelas mãos de um DD para upload.
  • Retornando ao Debian depois de terem sido excluídos por qualquer motivo. Por curiosidade, aqui há uma lista de pacotes a serem removidos em breve.
  • O pacote já estava no Debian mas, em virtude de um novo empacotamento (revisão Debian), ele agora gera um binário (.deb) a mais ou com nome diferente (um .deb foi renomeado).

Um pacote pode ficar de alguns minutos a 3 meses na NEW. O time FTP-Master não segue a ordem da fila. Como exemplo, considere que um deles chegue cansado do trabalho de noite mas tem como hobby analisar e aceitar pacotes. Só que o cansaço é tão grande quanto a vontade. Então, nesse caso, se for um analista que goste muito de Python, ele vai olhar pacotes que usem Python. É assim que funciona. O trabalho deles também é voluntário e é por isso que não seguem uma ordem. Assim sendo, pode ser que um determinado pacote seu pacote fique lá na fila 3 meses e um que você tenha enviado depois fique apenas 2 dias.

Ainda, se o pacote tiver problemas, ele não ficará na fila para sempre. Em determinado momento, ele será rejeitado. Se ele ainda não foi aprovado e nem rejeitado, é porque ainda não foi analisado.

Técnica de empacotamento

Quais modalidades de empacotamento estão disponíveis?

Há várias. Citando as mais comuns:

  • Manutenção de pacotes: ocorre quando você introduz um pacote novo no Debian ou adota um que esteja órfão. Nesse caso o pacote passa a ser seu e você vira um mantenedor de pacote (que é diferente de Debian Maintainer ou DM).
  • Trabalho de QA: é feito sobre pacotes que estão órfãos (sem um mantenedor atualmente). O objetivo é ajudar o pacote a evoluir, mesmo que ele não tenha um dono.
  • NMU (Non-maintainer upload): trabalho feito sobre um pacote que tem um mantenedor que não está tendo tempo de cuidar do mesmo. Admite apenas alterações para sanar problemas críticos.
  • Trabalho em times: nessa modalidade, você pode integrar um dos times de empacotamento no Debian e realizar trabalhos dentro do mesmo, com a supervisão e a ajuda de pessoas experientes no assunto.

Por onde começar a empacotar?

Para quem é iniciante, o ideal é começar por trabalhos de QA. Esse tipo de atividade não exige muito conhecimento e permite que sejam feitos apenas os ajustes que a pessoa conheça e domine. Com o tempo, cada um terá a habilidade de sanar todos os problemas e de passar para outras modalidades, como a de manutenção de pacotes.

Quais são os problemas mais comuns encontrados nos empacotamentos?

São vários. Os mais comuns para mim, quando atuando como sponsor são:

  • Não registrar no arquivo debian/changelog todas as alterações feitas em um pacote.
  • Não verificar com profundidade e paciência os dados de direitos autorais a serem inscritos no arquivo debian/copyright.

Esses são os problemas que mais ocorrem, dentre vários.

Como eu evito repetir problemas ou esquecer de algo em um pacote?

Simples! Crie um checklist!

Cada trabalho realizado em pacotes é um momento de aprendizado. Os seus sponsors, certamente, irão ensinar muito sobre empacotamento. Assim, a cada novo aprendizado, acresça itens no seu checklist básico.

O meu checklist básico como sponsor (e empacotador) está aqui.

Teria como eu saber qual versão de um programa está empacotado em outras distribuições, como Fedora?

Hum... Isso é interessante, pois você poderia, até mesmo, buscar patches feitos por outros mantenedores em outras distros.

Há um site muito interessante onde você poderá ver isso: https://repology.org/

Eu preciso renomear um pacote que já está no Debian. Como faço?

Siga as orientações que estão aqui.

Eriberto, você possui um plano de treinamento para quem quer aprender?

Sim, eu tenho um, mas nem sempre estou disponível. No entanto, quando treino alguém, uso o seguinte planejamento (vários dos códigos citados, como hello-newbie, estão disponíveis em http://debianet.com.br):

  • Empacotamento hello-newbie 0.1
  • Empacotamento hello-newbie 0.2
  • Empacotamento hello-newbie 0.3
  • Empacotamento hello-salad 0.1
  • Empacotamento hello-galaxy 0.1, a partir de agora com o uso de Git
  • Empacotamento hello-galaxy 0.2
  • Empacotamento hello-galaxy 0.3
  • Revisão hello-salad 0.1, agora com binários múltiplos
  • QA em pacote órfão com binários múltiplos e criação de repositório GIT no Salsa
  • QA em pacote órfão qualquer, sem manpage, com envio para experimental e criação de repositório GIT no Salsa
  • QA fechando bug no Ubuntu
  • Adoção de pacote órfão
  • Estudo do conteúdo do pacote devscripts e do /etc/devscripts.conf
  • Definir uso de determinados diretórios (DFSG)
  • Empacotamento hello-destructor
  • Análise de uma licença de software com base na DFSG e no teste da Ilha Deserta
  • Inscrever-se em um bug e em um pacote.
  • Revisão hello-old
  • Renomear o binário hello-old para hello-not-old
  • QA em pacote com DebSrc 1.0 e rules no formato antigo
  • QA em pacote nativo
  • ITP sobre código externo ou atendendo a RFP
  • Envio de pacote para Backports
  • Empacotamento hello-nightmare 1.150-beta1
  • Empacotamento hello-nightmare 1.2
  • Empacotamento hello-nightmare até o último commit
  • NMU 1
  • NMU 2
  • NMU em pacote marcado como LowNMU
  • QA em pacote com lintian duplicate-files
  • QA parcial escolhido pela relação de lintians dos orfãos
  • Conhecer um fonte que gere um pacote udeb. Ver rdate.
  • Estudo de pacote com múltiplos sources (airport-utils).

Geralmente, eu sigo a ordem que está acima. Dependendo da pessoa, outras tarefas, como revisões de pacotes em times, poderão ocorrer.

Há também procedimentos avançados, a serem feitos apenas por algumas pessoas:

  • QA de uma lib com lintian no-symbols-control-file
  • QA em pacote gráfico

Listas de discussão para aprendizagem e apoio

Em quais listas de discussão ou notícias eu deveria me cadastrar?

As seguintes listas de discussão ou notícias são essenciais para quem trabalha com empacotamento no Debian:

  • debian-announce - lista de notícias relevantes e de interesse geral sobre o Debian. Baixíssima circulação anual. Em inglês.
  • debian-devel-announce - lista de notícias relevantes para mantenedores de pacotes e para pessoas com envolvimento mais profundo no Debian. Baixíssima circulação anual. Em inglês.
  • debian-infrastructure-announce - lista de notícias relevantes sobre a infraestrutura do Debian. Muito usada para comunicar quando servidores específicos ficarão temporariamente fora do ar. Baixíssima circulação anual. Em inglês.
  • debian-legal - lista para discussões sobre o licenciamento de software no Debian. Extremamente interessante. Um ótimo lugar para aprender sobre licenciamento. Média circulação mensal. Em inglês.
  • debian-mentors - lista voltada para a retirada de dúvidas sobre empacotamento no Debian. Alta circulação mensal. Em inglês.
  • debian-devel-portuguese - lista nacional voltada para a retirada de dúvidas sobre empacotamento no Debian. Alta circulação mensal. Em português.
  • debian-br-eventos - lista nacional para o anúncio de eventos Debian no Brasil. Baixíssima circulação anual. Em inglês.

Existem outras listas de discussão do Debian?

Sim, existem. Caso você tenha interesses mais específicos, consulte todas as listas Debian em http://lists.debian.org. Há listas de todos os tipos. Na debian-jobs, por exemplo, você poderá encontrar ofertas de emprego para quem conhece Debian.

Chaves GPG

Por que eu deveria ter uma chave GPG assinada por DDs?

Inicialmente, você vai precisar de uma chave chave GPG para enviar pacotes para o repositório mentors.debian.net. Para fazer isso, essa chave não precisará da assinatura de DDs.

Se, um dia, você quiser se submeter ao processo para ser um DM ou um DD, precisará de ter uma chave RSA 4096 bits assinada por 2 DDs. Essa mesma chave será usada para você enviar os seus pacotes para o Debian, quando você já for um DM ou um DD. (neste mesmo FAQ eu já falei sobre o que vem a ser DM e DD e sobre o processo para se tornar um deles)

Eu quero criar uma chave. Como faço?

Como já foi dito anteriormente neste FAQ, siga as instruções existentes em https://wiki.debian.org/Keysigning. Siga os passos 1 a 7 COM ATENÇÃO. Lembro que a chave tem que ser do tipo RSA 4096 bits.

Eu quero assinar a chave de alguém. Como faço?

Inicialmente, você deve seguir algumas regras básicas. São elas:

  • Estar frente a frente com a pessoa que precisa da assinatura.
  • Mesmo que a conheça, solicitar um documento oficial com foto, como cédula de identidade ou carteira de motorista. Se for um estrangeiro, o documento deverá ser o seu passaporte.
  • Obter os dados básicos da chave da pessoa. São eles: nome completo, endereço de email e fingerprint da chave. Isso poderá ser fornecido, pela pessoa, a partir do seguinte comando:
$ gpg --fingerprint <nr da chave>
  • Conferir a foto e o rosto da pessoa.
  • Conferir o nome no documento e nos dados de chave fornecidos.
  • Levar consigo os dados referentes ao nome completo, endereço de email e fingerprint da chave. Há várias formas de fazer isso. Algumas:
    • Se a pessoa estiver com o seu notebook, pedir que ela emita o comando $ gpg --fingerprint <nr da chave>. A seguir, fotografe, com o seu telefone celular, a tela.
    • A pessoa também poderá entregar os dados por escrito (à mão).
    • Se a pessoa tiver um cartão de visitas com nome e email, ela poderá adicionar o fingerprint da chave no rodapé do cartão. Para ver exemplos, busque nas imagens do Google por "business card gnupg".
    • A pessoa poderá instalar o pacote signing-party e usar o comando gpg-key2ps para gerar "tirinhas" com os dados necessários. O resultado será um postscript que poderá ser impresso por programas como evince e okular. Exemplo:
$ gpg-key2ps -1 <nr da chave>   > tirinha.ps
$ evince tirinha.ps
  • Depois de conferir o documento e os dados da chave da pessoa, leve tais dados de chaves para casa e assine a chave.
  • A pessoa que desejar a assinatura tem que ter enviado a chave para repositórios públicos com o comando:
$ gpg --send-key <nr da chave>

Para assinar a chave da pessoa, utilize o comando caff. Veja um tutorial simples sobre isso em http://bit.ly/caffexim

Onde consigo mais informações sobre chaves GPG e assinatura?

Há diversos lugares que podem fornecer mais dados e curiosidades sobre chaves GPG. Nem todos estão atualizados, mas aqui estão alguns:

How to's

Como empacotar algo inédito no Debian? (ITP)

  • Você pode escolher um pacote inédito assim:
    • Opção 1: pesquisando na Internet em sites como GitHub, SourceForge etc. Escolha algo relevante e que não exista aos montes no Debian. Por exemplo, programas para encontrar arquivos dulpicados já existem, como rdfind, fdupes, duff, hardlink etc. Você pode empacotar algo similar a um pacote que já exista no Debian se ele tiver recursos interessantes e diferentes dos que já existem.
    • Opção 2: atendendo a uma solicitação de RFP (Request For Package) aqui.
    • Opção 3: procurando por um ITP (Intent To Package) antigo e, aparentemente, abandonado. Veja aqui.
  • Na opção 1, você deverá escolher um programa, testá-lo, empacotá-lo para ver se consegue fazer isso e abrir um bug ITP. Para abrir o ITP, use o comando $ reportbug (alternativamente você pode usar o reportbug gráfico). Quando ele perguntar o nome do pacote, digite wnpp.
  • Na opção 2, você deverá escolher um programa, testá-lo e empacotá-lo para ver se consegue fazer isso. Depois, deverá se tornar dono do bug e renomear de RFP para ITP. Exemplo para o bug #316594:
Debian Bug report logs - #316594
RFP: opengl-doc -- OpenGL API documentation
  • Você deverá enviar um email para control@bugs.debian.org, sem Subject, com o seguinte conteúdo:
retitle 316594 ITP: opengl-doc -- OpenGL API documentation
owner 316594 !
  • ATENÇÃO: não use GMail ou outro webmail se emitir o comando retitle. Esses ambientes irão quebrar as linhas antes da coluna 80 e "bagunçar" o comando retitle. Sugiro instalar o Sylpheed (apt install sylpheed) e configurá-lo para usar o GMail (o Sylpheed já tem um template para isso) ou outro sistema de email que você queira.
  • Para saber o que são os comandos de email anteriores, consulte este link.
  • Na opção 3, veja se o ITP está sem atividade há muitos dias. Envie um email para o bug (<nr_do_bug>@bugs.debian.org), com o assunto 'Re: <título original>', perguntando se a pessoa ainda tem interesse em empacotar. Espere 10 dias. Caso não haja resposta, envie outra mensagem dizendo que vai esperar mais 5 dias pela resposta. Se não houver resposta, torne-se dono do bug e empacote. Você vai mandar um email para control@bugs.debian.org, sem Subject, com o seguinte conteúdo, considerando que o bug seja o #775096:
owner 775096 !
  • EM TODOS OS CASOS ANTERIORES, utilize o comando $ apt search <pacote> dentro da jaula-sid para saber se o pacote já não existe no Debian Unstable (às vezes já existe e não fecharam o bug ou abriram um para o que já existe). Outro comando interessante é o $ wnpp-check <pacote>.
  • Também dê uma olhada na fila NEW, para ver se ele já não está lá.
  • EM TODOS OS CASOS ANTERIORES, no debian/changelog, só terá a linha:
* Initial release. (Closes: #<nr_do_ITP>)
  • Você não precisa citar cada alteração que fizer no empacotamento. Ao fazer upload, o seu pacote irá para a fila NEW, para ser inspecionado, manualmente, pela equipe FTP-Master, para entrar pela primeira vez no Debian. Um pacote poderá permanecer na fila NEW de 1 dia a 3 meses. A fila não é processada por ordem de chegada dos pacotes.
  • Se você abrir um ITP e desistir de empacotar, renomeie-o para RFP e deixe-o sem dono. Exemplo para o bug 123456789:
retitle 123456789 RFP: abc -- nice letters in screen
noowner 123456789
  • Você também pode buscar por pacotes que existam no Kali ou no Ubuntu e que não existam no Debian. Muito cuidado, pois essas distribuições possuem alguns pacotes que não são Software Livre. Se descobrir algo assim, por favor, adicione uma linha, em ordem alfabética, aqui. Para saber sobre pacotes que estão no Ubuntu e não estão no Debian, veja aqui. Os pacotes que estão no Kali mas que não existem no Debian estão aqui.
  • Caso você resolva empacotar algo que está no Kali ou no Debian, você poderá fazer isso do zero ou aproveitar o empacotamento já existente. Nos dois casos, você deverá abrir um ITP. No caso de aproveitar o empacotamento, mantenha o debian/changelog já existente e, no seu empacotamento, escreva:
* Initial release in Debian. (Closes: #<nr_do_ITP>)
  • Depois disso, cite todas as alterações feitas por você.

Como adotar um pacote órfão? (ITA)

  • Escolha um pacote órfão.
  • Declare ao mundo que irá adotá-lo. Uma vez que o pacote já está no Debian, você enviará um ITA (Intent to Adopt). O procedimento está aqui. Basicamente, você tem que enviar um e-mail para control@bugs.debian.org, sem assunto, com alguns comandos no corpo. Veja um exemplo:
retitle 625952 ITA: maximus -- Automaximizing window management tool
owner 625952 !
  • ATENÇÃO: não use GMail ou outro webmail se emitir o comando retitle. Esses ambientes irão quebrar as linhas antes da coluna 80 e "bagunçar" o comando retitle. Sugiro instalar o Sylpheed (apt install sylpheed) e configurá-lo para usar o GMail (o Sylpheed já tem um template para isso) ou outro sistema de email que você queira.
  • Para saber o que foi feito nos comandos de email anteriores, consulte este link.
  • No changelog do pacote, coloque na primeira linha:
* New maintainer. (Closes: #625952)

Como atender a um RFP?

O RFP (Request For Package) é um procedimento adotado por uma pessoa que não sabe empacotar ou que está sem tempo para isso. Utilizando a ferramenta reportbug, tal pessoa abre um bug contra o pseudo pacote wnpp, solicitando que algo seja empacotado.

Para atender a um pedido de empacotamento, siga as instruções abaixo.

  • Declare ao mundo que irá empacotá-lo. Você transformará o RFP em ITP (Intent to Package). O procedimento está aqui. Basicamente, você tem que enviar um e-mail para control@bugs.debian.org, sem assunto, com alguns comandos no corpo. Veja um exemplo:
retitle 119911 ITP: alephone -- marathon engine for related data games
owner 119911 !
  • ATENÇÃO: não use GMail ou outro webmail se emitir o comando retitle. Esses ambientes irão quebrar as linhas antes da coluna 80 e "bagunçar" o comando retitle. Sugiro instalar o Sylpheed (apt install sylpheed) e configurá-lo para usar o GMail (o Sylpheed já tem um template para isso) ou outro sistema de email que você queira.
  • Para saber o que foi feito nos comandos de email anteriores, consulte este link.
  • No changelog do pacote, coloque na primeira linha:
* Initial release. (Closes: #<nr_do_ITP>)
  • É importante ressaltar que o seu pacote irá para a fila NEW.

Como fazer um NMU?

O Non-maintainer upload (NMU) é feito quando o pacote já tem um mantenedor mas ele não está cuidando do mesmo por algum motivo (sem tempo, hospitalizado, viagem longa etc.). É feito com: 

# dch --nmu

Algumas recomendações:

  • Geralmente, só se faz NMU caso realmente seja necessário. Na maioria das vezes fazemos NMU referente a um bug importante, serious ou grave, considerando que o mantenedor não tenha tomado providências a tempo ou caso o pacote tenha um mantenedor mas esteja nitidamente abandonado. Veja mais detalhes aqui.
  • No NMU você só pode fazer o que for essencial para sanar o bug em questão. Nada mais.
  • No fim, um monte de lintians ficarão sem solução. É assim que tem que ser, pois você não pode sair mexendo em tudo (o pacote não é seu).
  • O upload do NMU, dependendo da situação, deverá ser feito com atraso, como visto aqui. Um upload poderá ser feito com até 15 dias de atraso. Isso será feito pelo seu sponsor (comando dput -e 15 pacote.changes).
  • Depois do upload (o sponsor avisará sobre isso), você deverá avisar nos bugs que fez um NMU, colocando uma cópia do changelog e anexando um debdiff (debdiff entre o .dsc antigo e o novo). Veja um exemplo aqui. Alternativamente, você pode usar o comando nmudiff, dentro do diretório do upstream no pacote, para gerar a mensagem de NMU. Evite criar um novo bug para tal mensagem (muitas vezes o nmudiff faz isso); use o(s) bug(s) RC já aberto(s), sempre que possível.
  • É possível fazer um NMU mais agressivo, mexendo em mais coisas, caso o mantenedor permita LowNMU. Também é possível fazer uma atualização completa do pacote, incluindo um "new upstream version", caso o pacote esteja realmente abandonado (por exemplo, um pacote com mais de 4 anos sem uploads; no entanto, essa avaliação é subjetiva e dependerá de vários fatores). Nesse caso, sugiro um upload com 15 dias de atraso, além da abertura de um novo bug declarando que está sendo feito um NMU completo.
  • Vale a pena olhar, no canto inferior direito do Tracker do pacote que precisa de NMU, se há algum patch do Ubuntu resolvendo o problema. Esses patches são gerados automaticamente quando os desenvolvedores Ubuntu sanam o problema e o pacote no Ubuntu fica diferente do pacote que está no Debian.
  • Outra boa tentativa é buscar patches em outras distribuições, como Arch e Gentoo. Para saber quais distribuições também possuem o pacote, acesse o site https://repology.org.

Onde encontrar possibilidades de NMU?

Para procurar por bugs RC, acesse:

Há também esse link:

Neste último, veja as colunas RC e o item "Top 200 sources in Debian Sid with RC BUGs".

Para ver os RC que você tem em pacotes instalados no seu Sid, use o comando: 

# rc-alert

Outra fonte para buscas, incluindo bugs important, é o seguinte UDD:

Antes de trabalhar no bug, olhe se não há nada sobre ele na fila de upload com atraso:

Se quiser fazer o download de algo que está na fila, use:

Como fazer um pacote para Backports?

Backports é um repositório que contém pacotes inéditos ou mais novos para stable. Esses pacotes são oriundos do testing. Essa técnica permite trazer pacotes mais novos do testing para o stable, sem fazer muitas alterações no stable, pois o referido pacote será reconstruído em uma jaula stable, usando as dependências do stable. Então, o seu stable não será inundado por libraries e dependências oriundas do testing ao instalar o pacote desejado (feito para Backports).

Para construir um pacote para Backports faça o seguinte:

  • Crie uma jaula stable.
  • Acesse https://backports.debian.org/ e leia o conteúdo dos links Instructions e Contribute MAS não faça nada ainda. Apenas entenda.
  • Na jaula stable, em /etc/apt/sources.list, adicione uma nova entrada deb-src apontando para o testing e uma outra deb apontando para o Backports. Exemplo, considerando "Buster" como atual stable:
deb http://ftp.br.debian.org/debian buster main
deb http://ftp.br.debian.org/debian buster-backports main
deb-src http://ftp.br.debian.org/debian testing main
  • Execute apt update e apt upgrade.
  • Busque o pacote desejado no testing com apt source.
  • Dentro do pacote execute dch --bpo. Usando o Debian 10 Buster como exemplo, o debian/changelog deverá ficar assim:
netdiscover (0.5.1-3~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.

 -- Joao Eriberto Mota Filho <eriberto@debian.org>  Mon, 05 Aug 2019 08:57:18 -0300
  • Execute debuild. Em princípio o seu pacote Backports está pronto, pois tal pacote deverá estar o mais próximo possível do que veio do testing.
  • Só faça alterações caso isso seja necessário para que o pacote possa ser construído e instalado. Em 99% dos casos não será necessário alterar nada.
  • Ignore TODOS os lintians (incluindo o backports-changes-missing).
  • Caso seja necessário utilizar uma versão mais nova de algum pacote para construir, verifique se o mesmo já não está presente no Backports. Por exemplo: o Debian Buster (stable atual quando este how to foi escrito) usa o DebHelper 12. Caso seja lançado o DebHelper 13 e você tenha no debian/control do pacote oriundo do testing um campo Build-Depends: debhelper-compat (= 13), não o altere para 12 sem antes verificar se a versão 13 já não está no Backports (use apt install -t buster-backports debhelper).
  • Caso você use controle de versão para o empacotamento e o servidor Salsa, trabalhe em uma branch backports. Não faça commits de backports na branch debian/master, que é dedicada ao unstable. Mesmo que você use controle de versão, para o Backports isso é opcional.
  • Teste o pacote, instalando-o no seu stable.
  • Finalmente, só faça Backports para os seus pacotes, para pacotes órfãos ou para pacotes de outros mantenedores que autorizarem isso. Para este último caso, se for necessário, você pode fazer um upload com atraso de 10 dias e abrir um bug declarando isso, nos mesmos moldes de um NMU.
  • Se o pacote estiver entrando no Backports pela primeira vez, ele irá para a fila NEW do Backports. Esse ciclo será renovado para cada stable que for lançado. Exemplo: você envia o pacote X para o Backports do atual stable. X irá para a Backports NEW. Os próximos uploads do X para o Backports serão aceitos automaticamente, sem passar pela NEW. Ao ser lançado um novo stable, o pacote X, se enviado para o Backports, irá para a fila NEW novamente.

Como fazer um upload para stable?

Uploads para stable são feitos para corrigir bugs críticos, para prover atualizações de segurança ou atualizações essenciais, como ocorre no caso de bancos de dados de antivírus. Não são permitidos uploads para stable por motivos fúteis. Geralmente, esses uploads são feitos para s-p-u (stable-proposed-updates).

Para entender o mecanismo e realizar o upload, siga os passos:

  • Leia (apenas leia, não execute ainda) o conteúdo do item 5.5.1 do Debian Developer's Reference, denominado "Special case: uploads to the stable and oldstable distributions".
  • Complementarmente, leia sobre The "proposed-updates" mechanism.
  • Em uma jaula stable faça dget em relação ao arquivo .dsc existente no stable (essa informação poderá ser facilmente encontrada no tracker). Caso você esteja usando Git como controle de versão no empacotamento, você poderá fazer checkout da tag relativa à revisão existente no stable e criar uma nova branch a partir deste ponto.
  • Dentro do diretório do upstream, execute dch --stable.
  • Aplique somente a correção necessária. Essa correção deverá ser mínima e também já deverá estar presente no unstable, o que evitará a propagação de um erro.
  • Faça um bom changelog relativo à correção aplicada.
  • Faça um debdiff entre o .dsc existente no stable e o novo .dsc, desviando o resultado para dentro de um arquivo chamado <nome_do_pacote>.diff.
  • Utilize a ferramenta reportbug, com a opção -A, para enviar um bug para o Debian. Depois da opção -A deverá ser colocado o nome do arquivo a ser anexado (que é o debdiff). Exemplo:
$ reportbug -A /tmp/hexedit.diff
  • O bug deverá ser criado contra o pseudo pacote release.debian.org.
  • No bug descreva o problema encontrado e a solução. Procure ser preciso e conciso. Se houver um bug (já fechado pelo upload no unstable), feche-o novamente. É interessante que haja um bug.
  • Assim que o upload for autorizado, envie o pacote. Se for preciso, passados 15 dias, envie um ping, ou seja, pergunte no próprio bug se alguém pode analisar o debdiff enviado (seja o mais polido possível e só faça isso em casos extremos!).
  • Para encontrar um exemplo real, basta executar dentro da distribuição stable:
$ dpkg -l | egrep '\+deb1'
  • Não esqueça de um dos passos mais importantes: testar o funcionamento do pacote no stable!
  • No changelog, o bug deverá ser fechado novamente para sinalizar que a operação também é válida para o stable.
  • Caso exista o mesmo problema no old-stable, considerando o tempo de suporte de 2 anos a partir do lançamento do stable, será bem vinda uma correção para o mesmo.
  • Links:

Como fazer um repositório .deb pessoal ou dentro da minha empresa?

Há duas formas de se fazer isso: a forma fácil e a melhor forma. A forma fácil é usando os comandos dpkg-scanpackages e dpkg-scansources. Procure sobre isso na Internet. Já a melhor forma é usando o mesmo mecanismo que o Debian usa, que é baseado no pacote mini-dinstall.

Há uma relação de métodos, como comparativos, aqui.

Como fazer uma boa manpage?

É fácil fazer uma manpage com qualidade. Use o txt2man e siga os passos:

  • Leia a manpage do txt2man para entender como ele funciona.
  • Siga os exemplos instalados em /usr/share/doc/txt2man/examples (comece pelo start-here.txt).
  • Se desejar use o script /usr/share/doc/txt2man/examples/create-man.sh para criar as manpages. Não esqueça que ele tem copyright e que se ele permanecer no diretório debian/, deverá ser citado no debian/copyright (geralmente em um bloco logo depois do debian/*).
  • Faça uma boa descrição do programa (geralmente com dados vindos do debian/control e do site do upstream).
  • Coloque todas as opções existentes no help (-h, --help) e no README do upstream.
  • Se necessário, adicione exemplos (seção EXAMPLES, veja os pacotes iwatch e chaosreader).
  • No fim sempre coloque os créditos do autor do programa e do empacotamento. Exemplo:
AUTHORS

chaosreader was written by Brendan Gregg.


This manual page was written by Joao Eriberto Mota Filho <eriberto@debian.org> for the Debian project (but may be used by others).

Veja exemplos reais no fim da manpage do pacote chaosreader.

  • Use o comando spell para procurar por erros ortográficos na manpage.
  • Use este site para verificar erros gramaticais. Cuidado, pois o site só aceita uma certa quantidade de caracteres se você não for assinante; assim, você terá que submeter a manpage por porções. Também seja crítico quanto às correções feitas, pois o nosso texto é técnico, é diferente.
  • Algumas vezes será necessário corrigir algumas frases do upstream. Não precisamos de um inglês perfeito por parte do upstream e do empacotador. Mas precisamos de algo aceitável.
  • Não tenha preguiça em fazer uma boa manpage. Às vezes ela será pequena, às vezes será enorme. No entanto, o seu nome aparecerá em diversos sites que listam manpages, junto com ela.

Como empacotar libraries C/C++?

O empacotamento de libraries em C/C++ exigem um pouco mais de estudo e conhecimento. Você deverá estudar sobre API/ABI e sobre o arquivo de símbolos no Debian, que serve para monitorar a possível mudança de ABI em uma nova versão da lib, podendo interferir em outros pacotes que dependam dela. Nesse caso, é sempre recomendável fazer o primeiro upload da nova versão da lib para experimental, para saber se a construção funciona ou não. Antes de passar para unstable, caso as mudanças sejam muito grandes, é bom verificar se os pacotes que dependem dessa lib funcionarão corretamente. Você também precisará saber o que é o SONAME (Shared Object Name) e o REALNAME.

O empacotamento da library, geralmente, será do tipo binários múltiplos. Em resumo, teremos um pacote -dev, que conterá cabeçalhos (arquivos .h) e outros objetos usados para a construção de pacotes (Build-Depends). O outro pacote conterá a runtime. O pacote -dev sempre dependerá do pacote runtime.

Para o estudo, siga a seguinte literatura, nessa ordem:

Dicas:

  • Se algum símbolo quebrar em alguma arquitetura durante a construção, você poderá marcá-lo como (optional).
  • Sempre teste a construção em uma jaula sid amd64 (64 bits) e em outra i386 (32 bits).

Exemplos de arquivos de símbolos:

Os pacotes distorm3 e libofa são bons exemplos para aprender sobre empacotamente de libs.

Pacotes sem símbolos: https://lintian.debian.org/tags/no-symbols-control-file.html

Por fim, para gerar símbolos, eu uso isso (depois de um debuild, execute isso na área do upstream; altere as variáveis LNAME e VER de acordo com o seu caso): 

LNAME=libtsk10; VER=4.1.3; dpkg-gensymbols -p$LNAME -Odebian/$LNAME.symbols -v$VER

Como fazer um empacotamento com múltiplos tarballs de upstream?

Nessa técnica haverá vários tarballs de upstream, gerando um binários apenas (arquivo .deb). Isso está disponível desde o formato 3.0 (quilt) e pode ser usado com softwares que possuem vários tarballs de upstream que seriam melhor distribuídos gerando-se um único .deb.

Em 29 de abril de 2023, 658 pacotes estavam utilizando esta técnica na seção main do Sid. Veja isso em:

Para entender como funciona o empacotamento de múltiplos tarballs de upstream, inicialmente, procure pela palavra "multiple" no link a seguir e estude os conteúdos desse link (são poucas linhas):

Normalmente, temos um tarball que servirá como base e um outro ou vários outros que serão integrados ao primeiro e que são conhecidos tecnicamente como "componentes" (component em inglês). Considere os seguintes tarballs:

  • exemplo-1.0.tar.gz
  • exemplo-controles-1.0.tar.gz
  • exemplo-dados-1.0.tar.gz

Digamos que desejamos empacotar o primeiro e usar os dois seguintes como componentes. As ações serão as seguintes:

  • Descompactar e debianizar o tarball exemplo-1.0.tar.gz. Considere que o diretório descompactado se chama exemplo-1.0/
  • Criar os diretórios controles e dados dentro de exemplo-1.0/. Nesse caso, o pacote final (.deb) se chamará exemplo.
  • Descompactar o tarball exemplo-controles-1.0.tar.gz e copiar todo o seu conteúdo para exemplo-1.0/controles/
  • Descompactar o tarball exemplo-dados-1.0.tar.gz e mover todo o seu conteúdo para exemplo-1.0/dados/
  • Renomear o tarball exemplo-controles-1.0.tar.gz para exemplo_1.0.orig-controles.tar.gz.
  • Renomear o tarball exemplo-dados-1.0.tar.gz para exemplo_1.0.orig-dados.tar.gz.
  • Dentro de exemplo-1.0, executar o comando a seguir (note que o "." representa o diretório atual e faz parte do comando):
 # dpkg-source -b .
  • Com o comando anterior, será gerado um arquivo .dsc, incorporando os tarballs exemplo_1.0.orig-controles.tar.gz e exemplo_1.0.orig-dados.tar.gz. Verifique o conteúdo do arquivo .dsc.
  • Finalize o empacotamento, ajustando os detalhes necessários.
  • Para fazer o arquivo debian/watch, gere uma linha para cada tarball. No caso dos dois componentes, utilize opts=component=<nome>. Exemplo:
 version=4
 
 https://darknet.com.br/exemplo-(\d\S+)\.tar\.gz
 
 opts=component=controles \
 https://darknet.com.br/exemplo-controles-(\d\S+)\.tar\.gz
 
 opts=component=dados \
 https://darknet.com.br/exemplo-dados-(\d\S+)\.tar\.gz
  • O debian/watch anterior irá gerar os nomes corretos para os tarballs ao fazer o download com uscan. Isso ocorrerá porque o uscan sempre usa o nome de source encontrado no debian/changelog ao fazer cada download. Com o opts=component, ele adicionará o nome de cada componente.
  • Caso seja necessário utilizar o comando uupdate para gerar o diretório de uma nova versão baixada com uscan, considerando que a nova versão é a 2.0, utilize o seguinte commando
 # uupdate -f -u -v2.0
 
 ou
 
 # uupdate -fuv2.0
  • O comando uupdate não gerará um .dsc, mas o comando debuild saberá fazer isso corretamente, pois enxergará o .orig-<componente>.tar.gz.
  • Quanto ao Salsa, o comando para importar o .dsc pela primeira vez, ou seja, # gbp import-dsc exemplo_1.0-1.dsc, também será capaz de perceber e importar os componentes. Verifique o resultado na branch pristine-tar.
  • Ainda no Salsa, no caso de já haver o repositório, no momento da importação de uma nova versão do upstream, como a 2.0, deve-se usar a opção --component com o comando gbp import-orig. Exemplo:
 # gbp import-orig ../exemplo-2.0.tar.gz --component exemplo-controles-1.0.tar.gz --component exemplo-dados-1.0.tar.gz
  • Também é possível indicar quais são os componentes no arquivo gbp.conf.

Diversos

Onde eu posso encontrar links interessantes sobre Debian?

  • Na minha página pessoa dentro do Debian você poderá encontrar muita coisa interessante e selecionada. Clique aqui.
  • Há também esta lista de estatísticas no Wiki do Debian.
Disponível em “https://eriberto.pro.br/wiki/index.php?title=FAQ_empacotamento_Debian&oldid=2787”