Conversei com alguns mantenedores no canal IRC do Debian, irc: //irc.debian.org#debian-mentors , pedindo exatamente a mesma coisa, e o consenso geral foi:
Solução 1:
A integração de dependências no seu pacote, copiando seus arquivos de origem como uma única base de código, é muito desaprovada. Isso anularia a finalidade de um sistema de empacotamento que lida com dependências, atualizações, controle de versão, etc.
Solução # 3:
Baixar pacotes não-debian on-the-fly ao instalar um binary ( .deb
) é um sério risco de segurança, definitivamente um não-não. Você nem conseguiria inspecionar as dependências extraindo as deb
, porque elas são baixadas e instaladas no momento da instalação. É uma abordagem que ignora completamente o sistema de repositórios. Nenhum usuário preocupado ficaria satisfeito com um pacote que, nos bastidores (e root
lembre-se!), Baixa software não confiável adicional de fontes não confiáveis. Sim, isso exigiria mexer com DEBIAN/postinst
(ou preinst
) e emitir um wget
(ou, no seu caso,pip install
) e essa é a abordagem adotada pelo Flash, Oracle Java, Steam e outros. Mas esse é um software proprietário e de código fechado; portanto, a segurança deles não é nenhuma.
Solução 1.5:
Você não mencionou isso, mas você poderia integrar as dependências somente em tempo de compilação , ou seja, na fonte do pacote (o .orig.tar.gz
, .debian.tar.gz
, .dsc
tríade), por meio de download PyPI ao criar o pacote "binário" (a .deb
). As instruções para o pip install
entrariam debian/rules
(observe as letras minúsculas debian
, ao contrário do pacote binário) e seriam executadas quando você emitir debuild
ou dpkg-buildpackage
.
Este é um meio termo entre os nºs 1 e 3. Atenua (mas não resolve!) Alguns dos problemas do n ° 3: pelo menos você pode inspecionar o produto final e .deb
não exigiria acesso à Internet no momento da instalação. Todos os riscos e encargos são transferidos do usuário final para o mantenedor do pacote. Mas, tem os mesmos problemas que o nº 1, pois ignora a maior parte da infraestrutura do sistema de empacotamento. Afinal, lidar com dependências (versões, atualizações, requisitos, conflitos) é por que dpkg
/ apt
foi criado em primeiro lugar! :)
Solução 2:
O único caminho certo ™ . Você cria pacotes debian para suas dependências, os lista como requisitos em seu pacote e envia todos os .debs
pacotes ou de origem.
A partir daí, você tem várias opções:
Envie os pacotes fonte, tanto seu software quanto suas dependências, para inclusão no Debian. Se aceito, eles estarão automaticamente disponíveis para todos os usuários do Debian, incluindo todos os derivados como o Ubuntu.
Carregue os pacotes de origem no Launchpad , criando assim um PPA que qualquer usuário do Ubuntu (e seus derivados como o Linux Mint) poderia facilmente adicionar e instalar
Hospede seu próprio repositório debian em seu site, para que usuários de qualquer sistema baseado em Debian possam adicionar /etc/apt/sources.list.d
e usar a apt
infraestrutura para baixar, instalar e manter atualizados (como o acima!)
Hospede os .deb
arquivos para download direto e instalação. Nenhuma apt
atualização automática ou envolveu o pensamento.
Quanto a como empacotar suas dependências PyPi (e seu software python também!), Existem várias ferramentas e referências que facilitam o processo:
stdeb , como você mencionou. Oldie e goodie.
Pybuild , uma ferramenta nova e incrível do Debian que substitui stdeb
.
E muitas referências úteis:
Preciso de ajuda? Confira aqueles: