Como e por que criar pacotes -dbg, -dev, -doc?


15

Estou escrevendo um pacote Ubuntu para um pacote que essencialmente fornece várias bibliotecas e cabeçalhos que são usados ​​para criar outro software. O pacote também é dividido em subpacotes menores, que são interdependentes; nesse sentido, o pacote é bastante semelhante ao boost.

Notei que pacotes como o boost fornecem

[...]
libboost-dbg
libboost-dev
libboost-doc
[...]
libboost-all-dev
[...]

mas nada que se chame pelo nome boostou libboost.

  • Qual é a ideia por trás disso?
  • Quais são os efeitos do -dbg, -deve -docpacotes?
  • Existem instruções fornecidas sobre como gravar arquivos de compilação para esses pacotes?

Respostas:


13

Idéia e finalidade

A principal razão para separar esses pacotes diferentes tem a ver com espaço em disco e velocidade de download. Em particular, é uma grande preocupação para o espaço espelhado, pois significa distribuir várias cópias dos dados. Ao fazer as foo-common, foo-dataou foo-docpacotes Architecture: all, nós só manter uma cópia dos dados no arquivo em vez de tê-lo copiado com cada arquitetura (por exemplo, i386, amd64, ect ...). Os símbolos de depuração não são necessários para a maioria dos usuários e acabam fazendo com que o download do pacote demore mais.

Para pacotes nos arquivos oficiais do Ubuntu, na verdade não há razão para criar -dbgpacotes manualmente. As máquinas de compilação -dbgsymeliminam automaticamente os símbolos de depuração e os colocam em pacotes hospedados no ddebs.ubuntu.com. (Veja: Pacotes de Símbolos de Depuração ) -dbgpacotes que existem são geralmente simplesmente transferidos do Debian.

Instruções

Quanto à implementação, dê uma olhada nesta pergunta:

Resumidamente, novas estrofes precisam ser criadas debian/controlpara cada pacote. Os debian/foo-*.installarquivos também precisam ser criados. Isso permitirá dh_installcolocar o conteúdo certo nos pacotes certos.

O foo.installpara o pacote binário principal pode se parecer com:

usr/bin/
usr/lib/

foo-common.install, foo-data.install, foo-doc.install, Ou o que quer:

/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/

E para foo-dev:

/usr/include/
/usr/lib/pkgconfig
/usr/lib/*.so

Criar o foo-dbgpacote requer edição, debian/rulespois normalmente dh_stripeliminará os símbolos de depuração. Portanto, precisamos substituir esse comportamento:

.PHONY: override_dh_strip
override_dh_strip:
        dh_strip --dbg-package=foo-dbg

12

O impulso é um exemplo complexo, vamos ver primeiro um mais simples.

Em termos precisos, o pacote fonte openssl fornece 5 pacotes binários:

  • libssl1.0.0contém a biblioteca dinâmica OpenSSL, versão 1.0.0. É para isso que os programas vinculados a esta biblioteca precisam ser executados. O nome do pacote contém um número de versão porque você pode ter outras versões da biblioteca instaladas ao mesmo tempo, se houver outros programas vinculados a outra versão que não seja compatível com o binário com a 1.0.0.
  • opensslcontém ferramentas de linha de comando que usam a biblioteca OpenSSL. Mesmo se você tiver várias versões da biblioteca, não precisará de várias versões dessas ferramentas: há apenas uma /usr/bin/openssle ferramentas, dados e documentação associados.
  • libssl-devcontém os arquivos necessários para compilar um programa vinculado ao OpenSSL. Existem arquivos de cabeçalho C ( *.h), bibliotecas para vinculação ( *.a, *.so) e alguns arquivos variados.
  • libssl-doccontém documentação para a biblioteca OpenSSL. Você só precisa deste pacote se quiser escrever programas que usam a biblioteca.
  • libssl1.0.0-dbgcontém símbolos de depuração. É útil apenas para pessoas que depuram a biblioteca OpenSSL ou programas que a utilizam. A resposta de andrewsomething tem mais informações sobre esses -dbgpacotes.

Além disso, o preciso contém uma versão mais antiga da biblioteca libssl0.9.8, porque existem programas que ainda estão vinculados à versão mais antiga.

Outros pacotes que você pode ver são ligações para idiomas diferentes de C. O OpenSSL não é fornecido com nenhum (existem ligações ao OpenSSL para outros idiomas, mas eles não são da mesma fonte). Um exemplo é o sqlite3 , que é fornecido com ligações TCL .

A principal razão para dividir pacotes como esse é que pacotes diferentes têm públicos-alvo diferentes. Um sistema em que ninguém jamais compila nada precisa apenas do libpacote principal e talvez das ferramentas de linha de comando; eles serão instalados automaticamente a partir de dependências, se necessário. Se alguém quiser compilar um programa que usa a biblioteca, precisará do -devpacote. Se alguém quiser escrever um programa que use a biblioteca, precisará do -docpacote.

E o Boost? Ele segue a mesma estrutura, mas como o Boost é uma biblioteca enorme, ele é dividido em muitos pacotes menores: libboost-*1.46.1e libboost-*1.46-dev. Precisamente, existe apenas uma versão do Boost, 1,46 , mas a oneiric tinha 1,42 e 1,46 . Há também um padrão de aumento de metapacote que puxa o pacote com versão como uma dependência.

Olhando para libhangul , além do pacote da biblioteca dinâmica libhangul1e do pacote de desenvolvimento libhangul-dev, há um pacote libhangul-data. Este pacote contém dados adicionais que são requeridos pela biblioteca. Mesmo se você tiver várias versões da biblioteca, elas poderão compartilhar o -datapacote. Além disso, o pacote é independente da arquitetura. O software que contém uma grande quantidade de dados independentes da arquitetura é dividido em pacotes dependentes e independentes da arquitetura, para economizar espaço nos sites de distribuição. Outro sufixo com um significado semelhante é -common.

As regras de empacotamento do Ubuntu e Debian são muito semelhantes, portanto, o material sobre a criação de pacotes Debian também se aplica ao Ubuntu. De fato, você pode ter o mesmo pacote de fontes para o Debian e Ubuntu; a única coisa que diferencia os pacotes Debian e Ubuntu é compilando-os em diferentes versões de bibliotecasm, e isso não passa da diferença entre os diferentes lançamentos do Ubuntu. Tenha a documentação do desenvolvedor Debian em mãos, especialmente o Manual de Políticas Debian e a Referência do Desenvolvedor ; consulte o New Maintainer's Guide para uma introdução. Ignore as partes sobre como trabalhar com o projeto Debian e assim por diante, apenas leia as partes sobre como criar um pacote.dh_make é uma boa maneira de começar com um pacote deb (você deve selecionar "Biblioteca").

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.