Tecnicamente um pacote DEB ou RPM poderia trazer grande parte das dependências do programa?

Baixei aqui o pacote DEB do Opera do próprio site do navegador e quando o abri com o Instalador de pacotes Qapt fiquei observando os arquivos a serem instalados no sistema, aqui uma pequena amostra só para dar contexto:

./usr/bin/opera
./usr/lib/x86_64-linux-gnu/opera/icudtl.dat
[...]
./usr/lib/x86_64-linux-gnu/opera/swiftshader/libGLESv2.so
[...]
./usr/share/icons/hicolor/128x128/apps/opera.png

Eu estava pensando, um pacote desses não poderia trazer consigo todas as suas dependências, ou pelo menos grande parte delas? Não estou nem dizendo um pacote que sirva para todas as distribuições, mas pelo menos que sirva para as duas últimas versões LTS do Ubuntu .

Preciso dizer que não defendo que isso fosse usado para todo programa (isso encheria o sistema de arquivos repetidos), mas mais para aqueles que não se encontram nos repositórios ou podem apresentar conflito de dependências, como foi esse caso aqui.

Não daria para criar, por exemplo, um pacote DEB completo do ePSXe ou Lutris que já tivessem boa parte de suas dependências dentro de suas próprias pastas. Quero dizer, em vez de depender do libcurl compartilhado por outros programas, o ePSXe e o Lutris poderiam instalar suas próprias versões do libcurl em suas respectivas pastas. Ou seja, teríamos ainda o /usr/lib/x86_64-linux-gnu/libcurl.so.4 para todos os programas, mas também o /usr/lib/lutris/libcurl.so.4 para servir ao Lutris e o /usr/lib/epsxe/libcurl.so.4 para servir ao ePSXe.

Por que isso não é feito?

1 Curtida

Tecnicamente sim, mas há formatos pensados desde o início para incluir o programa e suas dependências, como a AppImage. Um DEB com essa característica dependeria da gambiarra do LD_PRELOAD (o equivalente Linux de por uma DLL na pasta do programa).

2 Curtidas

@rasolar, os formatos AppImage, Flatpak ou Snap são o que você busca. Você pode ter mais detalhes de cada formato aqui.

1 Curtida

Já conheço esses formatos e até tenho um programa aqui em Appimage (O Etcher para ser mais preciso). Eu só queria saber se teoricamente o mesmo poderia ser alcançado com um tradicional pacote DEB ou RPM, da mesma forma que seria com um instalador EXE do Windows.

É possível sim tanto com RPM quanto como DEB. Vai da pessoa que está empacotando trilhar 2 caminhos:

  1. empacotar a(s) biblioteca(s) com as versões que ele precisa, podendo quebrar o sistema de quem está usando.
  2. listar a(s) versão(ões) mínima(s) da(s) biblioteca(s) que a aplicação precisa.

Feito isso é só mandar empacotar os software usando a ferramenta correspondente ao formato. No caso do RPM é o rpmbuild. Já para o debian é o dpkg.

Teoricamente, sim. Seria só fazer as adaptações necessárias. Porém, a ideia do .deb é, como os outros programas etc. no linux, compartilhar as bibliotecas. Logo, não faz sentido fazer isso. E como o pessoa já citou, existem formatos para isso atualmente e, você mesmo disse, já usa um deles.

Ah, enquanto eu escrevia o @LuisFK já tinha respondido.

Mesmo se seguir o esquema que falei de colocar as bibliotecas em pastas separadas, sem misturá-las às “bibliotecas globais” que servem a todos os outros programas? A explicação mais detalhada está no penúltimo parágrafo do meu post de abertura.

Isso seria uma gambiarra das brabas, além de consumir muito mais espaço do que ter uma só biblioteca dinâmica.

1 Curtida

Já imaginou depois ter que fazer um upgrade de distro e só depois descobrir que a aplicação não funciona por causa de ter sido capado o suporte a 32 bits?

Amigo Essa parte do pacote DEB completo nao eh usada pq n se precisa,
Apenas use
sudo apt install ./nome-do-pacote.deb
que ele já instala os pacotes dependentes tipo libs e cores ou ate msm consoles ou compiladores.
Espero ter auxiliado:grin: