antigamente , quem conseguia instalar e configurar um linux no pc, era o FILHO DO CHUCK NORRIS batizado.
Que nada! Eu conseguia. Uso linux desde 95. Mas você tinha que ter hardware bom ou então, um que fosse já testado pela distro.
MAS, o que atrapalha a facilidade é o grande número de tipos de pacotes compilados.
RPM, DEB, TGZ, etc....
Se o cara ta no Debian, e tem que instalar um pacote disponivel APENAS para o Fedra ele vai ter que apelar para o uso de conversores de pacotes (alien), e torçer para que dê certo.
Deveria ser criado um tipo de pacote universal entre as distros. Isso aumentaria a difusão de pacotes compilados, e consequentemente, organizando a gama de softwares disponíveis ao GNU/Linux.
Eu lembro que, no começo, no século passado, ferrei meu sistema por não respeitar uma regra de ouro:
evite ao máximo usar um pacote de outra distro. E eu usei RPM do
Mandrake no meu
Red Hat. O estrago já era previsível. Para a aplicação, o Red Hat usava 3 RPMs, o Mandrake usava 5. Entrei no loop das dependências infinitas e não consegui mais sair até que já sem paciência, usei o --force com a instalação e a vaca foi pro brejo em menos de 1 minuto e quase 1 hora de downloads.
Para entender o que aconteceu e o que acontece hoje em dia é necessário entender um pouco de empacotamento. Digamos que um
aplicativo X, para funcionar, precisa:
a - dos seus próprios arquivos executáveis
b - dos seus próprios arquivos de configuração
c - de um conjunto de bibliotecas seu
d - de um conjunto de bibliotecas do ambiente gráfico
e - de um conjunto de bibliotecas de terceiros
f - de cinco aplicativos comuns do sistema GNU
Os desenvolvedores do
aplicativo X se dividiram em dois times: um para o item
a e outro para o item
c, e ambos conversam sobre o que seus trabalhos vai mexer no arquivos do item
b.
A
distro 1 resolveu empacotar os itens da seguinte forma:
I - Criou um Meta-Pacote contendo apenas a informação de para instalá-lo ele precisa de resolver 10 dependências (os itens
a a
f, lembrando que o item
f possui 5 sub-itens).
II - Criou um pacote para os itens
a,
b e
c (sendo que nenhum desses pacotes tem qualquer informação sobre dependências)
III - Apontou qual o pacote de bibliotecas do ambiente gráfico necessário
IV - Apontou qual o pacote de bibliotecas de terceiros necessário
V - Apontou quais os cinco pacotes de arquivos executáveis necessários
Nessa situação, se você tentar instalar o pacote do item
a, ele vai instalar sozinho e o aplicativo não vai funcionar. Se instalar os pacotes dos itens
a,
b e
c pode até rodar corretamente, desde que no seu sistema as outras dependências estejam satisfeitas. Todavia, apenas se você instalar o Meta-Pacote, é que se terá garantia sobre o funcionamento do aplicativo.
A
distro 2 resolveu empacotar os itens da seguinte forma:
I - Criou um pacote contendo os itens
a e
b e com apenas a informação das dependências dos pacote dos item
c a
f.
II - Criou um pacote para o item
b com a informação que depende do pacote supracitado
Nessa situação, se você tentar instalar qualquer dos dois pacotes ou os dois ao mesmo tempo, seus conjuntos de dependências serão satisfeitos e o aplicativo vai funcionar. Entretanto, se alguém estiver interessado no conjunto de bibliotecas do
aplicativo X e fizer um
aplicativo Y que dependa dessas, mesmo precisando apenas delas, a distro vai instalar todo o
aplicativo X só porque você pediu para instalar o
aplicativo Y e este tinha uma dependência que também possuía as suas.
A
distro 3 resolveu empacotar da seguinte forma:
Criou um "super pacote" contendo os itens
a a
c e apontando para todas as dependências dos itens
d a
f.
Nessa situação, se você instalar o pacote, seu conjunto de dependências vão ser satisfeitos e o aplicativo vai funcionar. Porém, a correção de bugs dos itens
a e
c são feitas por times independentes e só quando a distro achar que deve atualizar o pacote é que o usuário vai se beneficiar do trabalho de ambos os times e ter finalmente "aquele" problema resolvido (toda vez que ele tentava executar um determinado procedimento e o programa simplesmente fechava). Com a atualização, ele pulou 3 versões de arquivos executáveis e 2 versões de bibliotecas, mas para ele, que atualiza todos os dias, ele não pulou nenhuma versão do pacote.
Todo mundo conhece o que é "
um pacote depender de outro", mas talvez poucos sabem o que realmente um pacote tem e faz. Além das dependências e milhares de outras funções, gostaria de ressaltar algumas:
- é compactado
- guarda informações sobre a descrição do conteúdo e para que serve; dependências; responsável pelo empacotamento; distro do pacote; etc
- os arquivos dispostos nele como se estivesse na própria árvore da distro para serem assim distribuídos
E é nesse último ponto que quero dar maior ênfase. Existe um padrão "
Linux Standard Base (
LSB)" que entre muitas resoluções em diversas áreas de um sistema
GNU/Linux,
orienta inclusive como deve ser a árvore de diretórios. O respeito a esse padrão pode determinar uma maior compatibilidade entre as distros. Assim, se um aplicativo procura determinado arquivo num certo caminho, terá sucesso tanto naquela distro quanto noutra que respeite as mesmas regras.
Contudo, a
LSB, apesar de ser bastante ampla, não abrange todos os assuntos, não prevê todas as hipóteses e está em desenvolvimento da mesma forma que tudo no mundo. Assim, pode acontecer que se tenha uma solução sólida para duas distros que pode não estar na pauta da
LSB, sendo que ambas tomaram rumos diferentes e, naquele ponto, são incompatíveis entre si. Quando a
LSB tratar do assunto (se um dia tratar), o fruto da
negociação e debate não será jamais uma imposição duma solução sobre as demais existentes, lembrando que todas as distros são
autônomas.
Portanto, ainda que você tenha sucesso na conversão de um pacote de determinada distro para a sua, também se deve ter sorte para que ambas as distros ou respeitem, naquele determinado assunto, as regras da
LSB ou tenham a mesma orientação.
