Que convenções de pacotes existem para o Ubuntu?

Question

É difícil descrever essa questão. Vamos ver um exemplo:

O pacote blender depende, por exemplo, de blender-data . Eu olhei em ambos os pacotes. blender contém apenas o aplicativo, um arquivo .desktop e algo parecido, enquanto blender-data também contém os ícones do aplicativo e assim por diante. Se eu baixar o liquidificador do site original, não recebo nenhum pacote, mas uma pasta com tudo que eu preciso.

Por que há um pacote de dados para o liquidificador? Existem mais dessas convenções? Que tipo de pacotes existem? Onde posso ler mais sobre isso? Eu encontrei muitas informações sobre como empacotar e detalhes internos, mas nada sobre convenções de nomenclatura e o motivo para criar *-data packages.

    

Answer 1

Para responder à sua pergunta aqui, eu vou usar o LibreOffice como exemplo (como quase todo mundo já instalou). Se você está no Lubuntu (que não tem o LibreOffice como suíte de produtividade de escritório padrão) e instala o LibreOffice, é um pacote quase vazio embora tenha dependências de pacotes para o Writer , Calc, Base, etc.

Uma dependência de pacote é apenas um "ponteiro" para outro pacote. Caso contrário, os servidores da Canonical (a empresa por trás do Ubuntu) seriam rapidamente preenchidos com pacotes duplos, triplos, quádruplos ... contendo todos os mesmos arquivos!

Um pacote que, em si mesmo apenas , contém tais "ponteiros" é conhecido como meta package .

Portanto, o pacote meta do LibreOffice extrai seus pacotes separados (por exemplo, calc ), o que atrai suas dependências, o que puxa as deles até que todas as dependências sejam resolvidas.
Você pode entretanto instalar apenas o Calc sem nenhum dos outros pacotes.

Para ver isso em ação, digite o seguinte comando em um terminal:

apt-cache depends libreoffice-calc

E blender é apenas um exemplo muito simples dos itens acima.

Mais alguns detalhes:

Para alguns pacotes, as coisas são divididas em unidades funcionais: não é incomum ver pacotes chamados: application, application-data, application-plugins, application-dev e outros que contêm, respectivamente, o próprio aplicativo, um dataset ou dados para operar contra, alguns plugins, ou qualquer outra coisa ...

Para os detalhes completos:

Visite o Wiki de desenvolvimento de gerenciamento de pacotes.

    

Answer 2

Além da resposta de Fabby, há mais um ponto a considerar: a dependência da arquitetura do conteúdo do pacote.

Por exemplo, o programa blender em si dependerá obviamente da arquitetura do SO - você só pode executar amd64 binários em amd64 SOs. No entanto, muitos dados não são tão dependentes - os arquivos de ícones, traduções, programas escritos em linguagens como Python ou Java, por exemplo, podem ser os mesmos para todas as arquiteturas.

Assim, um primeiro passo para otimizar o conteúdo do pacote é dividir esses arquivos em pacotes comuns que são dependências da versão específica da arquitetura. Os arquivos comuns, geralmente em pacotes com -data , possuem a arquitetura all . Os pacotes binários e de biblioteca têm valores de arquitetura de amd64 , i386 , armhf , etc.

Esta é, na verdade, uma das Melhores práticas de empacotamento recomendado pelo Debian:

  

Não é incomum ter uma grande quantidade de dados independentes de arquitetura empacotados com um programa. Por exemplo, arquivos de áudio, uma coleção de ícones, padrões de papel de parede ou outros arquivos gráficos. Se o tamanho desses dados for insignificante em comparação com o tamanho do restante do pacote, provavelmente é melhor manter tudo em um único pacote.

     

No entanto, se o tamanho dos dados for considerável, considere dividi-los em um pacote separado e independente de arquitetura ( _all.deb ). Ao fazer isso, você evita a duplicação desnecessária dos mesmos dados em onze ou mais .debs, um para cada arquitetura. Enquanto isso adiciona alguma sobrecarga extra nos arquivos Packages , ele economiza muito espaço em disco nos espelhos do Debian. A separação dos dados independentes de arquitetura também reduz o tempo de processamento do lintian (consulte Seção A.2 , “Package lint tools” ) quando rodar por todo o repositório Debian.

Esses arquivos independentes de arquitetura geralmente entram em /usr/share - na verdade, é uma violação de política ter arquivos dependentes de arquitetura nessa árvore de diretórios.

Então, uma maneira de organizar as coisas ocorre naturalmente:

all
├── doc      # man pages, documentation in other formats
├── icons
├── themes
├── translations
└── etc.
arch
├── bin      # binaries
├── dbg      # binaries with debug symbols
├── lib      # shared library files
└── lib-dev  # header files and other shared library files for development