Modernização e Avanço do Linux.

25. Re: Modernização e Avanço do Linux.

tipoff
(usa Nenhuma)

Enviado em 20/11/2024 - 10:29h

Delusion escreveu:

sobre formas de disponibilizar o software, vejo que o pessoal que gosta de flatos ou snap sempre argumentam isso de que precisa empacotar para 300 distros diferentes.
uma pergunta de leigo:
não seria só fazer um .deb, um .rpm e outro para a base arch? (que não sei qual é), ou seja;
embora sejam muitas distros, parece que 99% delas estão num desses 3 formatos.
não vejo distros fora desses formatos com projeção de uso, pelo menos não no mundo binário; compilação a partir do fonte, talvez.

Na verdade o .deb e o .rpm já são padrões estabelecidos quando se trata de disponibilização de softwares no Linux, vide o Google Chrome, Steam, etc. O pessoal do Arch se vira fazendo repackaging desses pacotes pelo AUR, como acontece com o Google Chrome ( https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-chrome#n35 ).

Empresas como a Google e a Valve tem recursos ($$$) de sobra para investir em pessoas para manter pacotes .deb e .rpm funcionando nas grandes distros. Empresas menores ou desenvolvedores independentes não tem todo o tempo do mundo e recursos para ficar corrigindo pacotes quebrados quando ocorre uma atualização de distro ou quando sai uma distro nova do forno.

E o problema disso tudo tem nome e sobrenome: bibliotecas compartilhadas. Cada distro baseada em Debian, por exemplo, tem suas peculiaridades, como versões diferentes de bibliotecas (libs) e pacotes, além da versão da distro. Com isso, não é garantido que o mesmo pacote .deb vá funcionar em todas as distros baseadas. É o caso dos pacotes .deb obtidos por PPAs do Ubuntu. Quantas vezes alguém quebrou o sistema tentando instalar um .deb de um PPA avulso no Debian? Só aqui no fórum, já li diversos casos.

As bibliotecas compartilhadas são a base fundamental dos gerenciadores de pacotes, seja ele o apt, o dnf, pacman, zypper, etc. Quanto maior o número de dependências (bibliotecas) que o pacote exige, mais amarração no sistema ele terá, o que dificulta a manutenção do pacote e também futuras atualizações.

As empresas como a Google e a Valve utilizam-se de um truque para fornecer seus softwares para Linux. O Google Chrome e a Steam dependem de bibliotecas compartilhadas, mas algumas delas são inclusas junto com o pacote. Depois, dê uma olhada na pasta de instalação da Steam ou do Google Chrome no seu sistema, vai notar que há algumas bibliotecas .so soltas na mesma pasta do executável.

Essas bibliotecas inclusas são bibliotecas críticas para o funcionamento desses pacotes, que sobrescrevem as bibliotecas compartilhadas do sistema em tempo de execução. É feito um malabarismo para forçar o software a usar essas bibliotecas ao invés das do sistema, e isso é feito para evitar quebra de pacotes e manter compatibilidade com o maior número de distros.

Ai que entra os gerenciadores de pacotes universais. Eles usam uma variação desse truque, incorporando essas bibliotecas em containers e simplificando o processo de construção do pacote. Um mesmo flatpak pode ser utilizado no Ubuntu, Debian, Mint, Arch, Fedora, e no Linux do zézinho que acabou de lançar. Isso garante agilidade e simplifica bastante a disponibilização de novos softwares para Linux, sem mexer na estrutura de pacotes e dependências do sistema.

2 0

Quote