Como instalar verdadeiramente um arquivo tar.gz no Linux - como gerenciar aplicativos instalados manualmente (ou independentes)?

Question

Eu vejo todos esses links explicando pacotes e .debs ... Eu sei disso ... e há muitos kludges para obter arquivos tar.gz funcionando (por exemplo: update-alternatives para Java ou descartar manualmente o arquivo em / usr / local / bin (ou em outro lugar, que eu tinha deduzido de horas de pesquisa)). Se os pacotes são tão inteligentes, como são tão poucos aplicativos Linux disponíveis em pacotes ou .debs / rpms?

Estou falando como um novo usuário; Eu sei que os especialistas provavelmente sabem melhor (acho que posso baixar uma versão compilável do Eclipse?). Como o netbeans e o chrome são .sh , eclipse é um diretório simples, o Java requer esse update-alternatives business mas eu não acho que ele se registra na "lista de programas" do Ubuntu / Debian (apenas registra como um comando), etc (Eu sei que estas estão algumas vezes disponíveis em repositórios, mas estou confuso porque as páginas de download não possuem explicações apropriadas).

Longa história curta: Se você baixar ou compilar um arquivo tar.gz, como faço para registrá-lo no sistema? update-alternatives parece registrá-lo como um comando, no Ubuntu, ele não aparece na barra de pesquisa. No Debian, posso adicionar manualmente um atalho ao iniciador do GNOME 2. Mas o que eu realmente deveria estar fazendo?

Editar:

Então, depois de brincar um pouco mais com as novas soluções, posso refinar meu "problema":

Como devo gerenciar meus programas instalados manualmente? Firefox e Eclipse são meus únicos exemplos até agora (eu não baixo muita coisa). Ambos podem ficar sem a caixa, o que eu gosto. Exceto, onde devo instalá-los? Eu vejo o Eclipse tem suas próprias instruções, mas eu prefiro fazer todos os meus "pacotes manuais" da mesma maneira.

1. Depois de algumas pesquisas, decidi colocar esses programas em /usr/local/bin .
2. De como instalar o eclipse , resolvi conseguir algo para aparecer no lançador, eu preciso colocar um arquivo xxx.desktop em ~/.local/share/applications/ . O nome deste arquivo .desktop é importante?
3. Coisas com ferramentas automáticas (eu procuro um arquivo configure ou unix/configure ) funcionarão bem. Alguns pontos de pesquisa que eu deveria usar CheckInstall para acompanhar todos estes.
4. Eu deveria usar update-alternatives para registrar caminhos. A partir deste segmento de Java , parece que eu criei um link de /usr/bin/java a /usr/lib/jvm/jdk... . Quando instalo esses aplicativos "independentes", como o Eclipse ou o Firefox, devo sempre vincular a /usr/bin/[app] ? E se a afirmação 1 for verdadeira, eu estaria fazendo coisas como sudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Estas instruções estão corretas / são uma boa maneira de gerenciar instalações manuais? Existem outras etapas que devo seguir? Outras sugestões?

    

Answer 1

Por que muitos aplicativos não estão disponíveis em repositórios de pacotes?

Pode haver muitas razões:

• Ninguém se preocupou em empacotar o aplicativo.
• Ninguém tem permissão para empacotar o aplicativo (como Oracle insistindo em ser o apenas um para distribuir o Java ).
• O pacote é publicado sob uma licença que contradiz os valores das distribuições.
• ...

Não há um único motivo. Se quiser ver seu aplicativo favorito no gerenciador de pacotes da sua distro, você deve tratar cada caso separadamente. Tente entrar em contato com os desenvolvedores (em um canal de IRC ou uma lista de discussão, por exemplo) e pergunte como você poderia ajudar na embalagem.

Como instalar um tarball?

Um tarball (pacote .tar.gz) pode conter qualquer coisa. Até você realmente abri-lo, você não tem como assumir como instalá-lo. Mais uma vez, cada pacote deve ser abordado de forma diferente.

Procure documentação! Qualquer pacote (semi-) decente fornecerá instruções sobre como instalar o aplicativo. Seu primeiro reflexo deve ser sempre procurar um arquivo de texto chamado README, INSTALL ou algo assim. Verificar o website do editor também pode ajudar.

Como cada pacote é diferente, não há uma maneira universal de processar todos os pacotes do mundo. É como pedir uma receita que funcione com todos os ingredientes do mundo. Não está acontecendo.

Um bom conhecimento do seu sistema, sua distro e seu ambiente de trabalho ajudarão, então, se isso for reconfortante, as coisas parecerão cada vez mais previsíveis à medida que você passa tempo no mundo linux.

Um caso especial: Autotools

À medida que os projetos crescem, eles precisam fornecer maneiras fáceis de passar do código-fonte para o binário e para a instalação completa no sistema. É por isso que eles são fornecidos com um sistema de criação incorporado, uma coleção de scripts para fazer o necessário.

No mundo do Linux / Código Aberto / Software Livre, um sistema de construção tem uma adoção mais ampla: GNU Autotools . Se você já lidou com um pacote fonte (n aberto), há uma grande chance de usar o Autotools.

No caso mais simples, veja como instalar um aplicativo empacotado com autotools:

• ./configure : Um script que irá gerar os Makefiles correspondentes ao seu sistema (ele também verifica frequentemente a disponibilidade de dependências).
• make : Compilando o código fonte de acordo com os Makefiles gerados anteriormente.
• make install : copia os binários para os locais apropriados, cria links simbólicos e qualquer outra etapa definida pelo desenvolvedor.

Notas

• Os scripts configure geralmente têm muitas opções, como qual compilador usar ou como definir o diretório de destino. Se você precisa de flexibilidade, vale a pena olhar para ./configure --help .
• Mesmo se tiver certeza de que é o Autotools e você o conhece muito bem, sempre comece lendo os documentos (README, INSTALL, ...)

Responda à atualização na pergunta

O que você está pedindo não tem uma resposta definitiva. Todos aqui podem ter uma opinião sobre o que constitui "boa prática", mas no final do dia, só você pode encontrar o que funciona para você . Se houvesse uma resposta fácil, você não estaria fazendo a pergunta. Sua distro teria respondido por você.

Dito isto, aqui estão algumas observações pessoais.

• No meu sistema, eu reservo /usr/local/bin para os pacotes instalados pelo meu gerenciador de pacotes. Tudo que eu compilar / instalar manualmente entra em /opt . Este é um detalhe, mas ajuda a evitar grandes dores de cabeça ao lidar com várias versões do mesmo programa.

• xxx.desktop e problemas de GUI em geral são específicos do ambiente de área de trabalho que você está usando. Se funciona para o seu sistema, ótimo. Mas não pode ser generalizado para todos os ambientes disponíveis no Unix.

• /usr/local/bin tem a vantagem de já estar em seu PATH . Se você quiser usar outro diretório (como /opt como eu sugiro), certifique-se de incluí-lo no seu PATH. Se você não sabe como fazê-lo, abra um terminal e execute o seguinte em um terminal (não a maneira mais bonita de fazê-lo, mas sem saber nada sobre o seu sistema, não posso sugerir mais nada): echo 'export PATH=$PATH:/opt' >> ~/.bashrc

Answer 2

Eu acho que você tem que esclarecer com você mesmo o que você quer "registrar" com .

Para explicar - e eu não estou tentando ser esperto - "linux" é, claro, o kernel, e o kernel não conhece e nem tem interesse em nenhum dos softwares de espaço do usuário em seu sistema além do init. Então, do que estamos falando aqui?

Você menciona várias distros diferentes. Eu às vezes construo software a partir do código-fonte, mesmo que ele esteja disponível no repositório, porque eu quero algumas opções de configuração configuradas que não estão definidas no binário da distribuição. O único problema que tenho com isso é que se o pacote é um pré-requisito para outra coisa, eu realmente tenho que registrar isso com o sistema de empacotamento para evitar a instalação acidental do pacote distro no topo do pacote. um que eu construí Em sistemas baseados em fedora / rpm, isso é feito com rpm -i --justdb <package> . Eu não faço isso em sistemas baseados em debian / apt; em vez disso, apenas forço as instalações conforme necessário, o que talvez seja um pouco preguiçoso - parece haver uma maneira mais agradável de fazer isso , criando um pacote fictício que finge cumprir qualquer pré-requisito. Isso é o tipo de sugestão do m0nhawk de realmente criar um pacote a partir da fonte .tar.gz - exceto um pouco mais simples (eu vou ser honesto e dizer que eu não gosto da sugestão do m0nhawk).

Parece que você tem alguns outros problemas além do sistema de empacotamento. Não está claro para mim quais são esses, embora você mencione o ambiente de desktop (por exemplo, Gnome). Estes são heterogêneos, então simplesmente não há uma resposta para a pergunta, "como faço isso no linux" - não é nem uma questão de "como faço isso no Ubuntu" ou "como faço isso em gentoo "- é uma questão de" como faço isso para o desktop gnome "ou" como fazer isso na área de trabalho XFCE ", etc. Na minha opinião, o único problema é a questão dos lançadores que você mencionou, que eu gostaria de acreditar que cada DE fornece um meio simples de fazer isso (mas não será exatamente o mesmo, porque eles são diferentes). Existe também a questão de ter algo que forneça um padrão para lidar com arquivos - acho que a questão é "como eu registro um comando com meu navegador de arquivos" (e navegadores de arquivos no linux também são uma coleção heterogênea). p>

Depois, há serviços, que são gerenciados pelo sistema init (por exemplo, systemd ou upstart). Portanto, essa questão é, na verdade, uma série de perguntas relacionadas relacionadas a:

• o sistema de empacotamento, por exemplo, apt ou yum
• o sistema init, por exemplo, systemd ou upstart
• o ambiente de trabalho, por exemplo, kde ou unidade
• o filebrower, por exemplo, nautilus ou konqueror
• ?????

Parte do motivo não pode haver uma solução unificada simples (embora o padrão XDG possa fornecer algumas partes de tal) é que "linux" não é um sistema operacional unificado simples e imagino que a grande maioria dos seus usuários preferem assim. Eu geralmente não uso um DE, e nunca uso o navegador de arquivos que eles vêm, etc.

Mais uma vez, estou realmente tentando ser útil com isso e não apenas pontificar: se há problemas que você quer resolver aqui, você terá que considerar com mais precisão quais são esses problemas e quais softwares estão realmente envolvidos com eles. apenas "linux") se você quiser resolvê-los.

    

Answer 3

Eu acho que a razão básica para o seu problema geral é que um sistema Linux por si só não contém um "registro" como tal. Um arquivo executável é tudo o que você realmente precisa para algo rodar. Se você não quiser especificar o caminho completo para o executável, a maioria dos shells os procurará nos diretórios listados na variável $ PATH do seu ambiente. Pode ficar um pouco mais complexo com bibliotecas vinculadas e assim por diante, mas normalmente você não precisa se aprofundar tão longe.

Diferentes distribuições de Linux padronizaram vários layouts de sistemas de arquivos e sistemas de gerenciamento de pacotes, aí está o problema. Os Redhats usam rpm , Debians / Ubuntu usam pacotes deb. O Arch também seguiu seu próprio caminho . Do ponto de vista de projetos de software, a menos que você queira ser incluído em uma distribuição, sua base de usuários é inteiramente em uma distro, ou um produto comercial que visa facilitar a instalação de todos, eles provavelmente são os únicos pontos que você começa a construir vários pacotes.

Na verdade, uma fonte tar.gz que construa com gcc é provavelmente a melhor definição de um "pacote Linux" comum. Um kernel do Linux com alguns utilitários GNU e GCC apenas sobre o denominador comum entre todos os diferentes tipos de sistemas operacionais baseados em Linux que você pode obter.

Eu não iria tão longe quanto dizer que "tão poucas" coisas estão disponíveis como pacotes porque algo específico que você está procurando não é. (ou talvez o distribuidor tenha escolhido não se incomodar com toda essa confusão de pacotes? Como o Chrome e seu próprio processo de atualização). Há tão que muitos pacotes em torno de por isso muitos sistemas para tantas arquiteturas para tantos softwares livres que não são divertidas .

Se você construiu algo que não é fornecido como um pacote para sua distribuição de linux, ou suporta a opção de construir como pacote, a melhor maneira de "registrá-lo" como um pacote real é construir um pacote para ele, definindo onde todos os arquivos devem ir com base no sistema de pacotes escolhido e instalá-lo dessa maneira. Seja uma alma e contribua com seu trabalho de embalagem para o projeto, para que outros possam se beneficiar dele.

Existem vários guias na Web sobre construindo pacotes . Debian sendo um deles .

Se tudo o que você quer fazer é executar um pacote compilado, talvez adicione o caminho binário ao seu $PATH ?

Se você está fazendo outra coisa, o que é isso?

    

Answer 4

Gostaria de acrescentar que você também pode link simbolicamente para ~/bin/ em vez de /usr/bin . Os arquivos *.desktop podem ser colocados em ~/.local/share/applications/ ou /usr/share/applications/ . Só eu uso meu computador e gosto de evitar tocar nos arquivos do sistema (qualquer coisa fora do meu diretório pessoal) o máximo possível.

É claro que, quando você coloca coisas nas contrapartes do "diretório base", elas não são exibidas para outros usuários.

Isto é o que está incluído no padrão ~/.profile para debian wheezy:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi