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

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

Estou falando como um novo usuário; Sei que os especialistas provavelmente o conhecem melhor (acho que posso baixar uma versão compilável do Eclipse?). Como o netbeans e o chrome .sh, eclipse é um diretório simples e ativável, o Java requer esse update-alternativesnegócio, mas eu não acho que ele se registre na "lista de programas" do Ubuntu / Debian (apenas registra como um comando), etc. (eu sei que esses são às vezes disponível em repositórios, mas estou confuso por que as páginas de download não têm explicações adequadas).

Resumindo: se um download ou compila um arquivo tar.gz, como faço para registrá-lo no sistema? update-alternativesparece 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 (não baixo muitas coisas). Ambos podem ficar sem caixa, o que eu gosto. Exceto, onde devo instalá-los? Vejo que o Eclipse tem suas próprias instruções, mas prefiro fazer todos os meus "pacotes manuais" da mesma maneira.

1. Após algumas pesquisas, decidi incluir esses programas /usr/local/bin.
2. De como instalar eclipse , eu imaginei para conseguir algo para aparecer no lançador, eu preciso colocar um xxx.desktoparquivo em ~/.local/share/applications/. O nome desse arquivo .desktop importa?
3. Material com autotools (eu olhar para uma configureou unix/configurearquivo) vai funcionar muito bem. Algumas pesquisas apontam que devo usar CheckInstallpara acompanhar tudo isso.
4. Eu devo usar update-alternativespara registrar caminhos. A partir desse encadeamento java , parece que eu crio um link de /usr/bin/javapara /usr/lib/jvm/jdk.... Quando instalo esses aplicativos "independentes", como o Eclipse ou o Firefox, devo sempre conectar-me /usr/bin/[app]? E se a afirmação 1 for verdadeira, eu estaria fazendo coisas comosudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

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

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

Poderia haver muitas razões:

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

Não há uma única razão. Se você deseja ver seu aplicativo favorito no gerenciador de pacotes da sua distribuição, trate cada caso separadamente. Tente entrar em contato com os desenvolvedores (em um canal de IRC ou em uma lista de discussão, por exemplo) e pergunte como você pode ajudar a empacotar.

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. Novamente, cada pacote deve ser abordado de maneira diferente.

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

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

Um bom conhecimento do seu sistema, da sua distribuição e do ambiente da área de trabalho ajudará; portanto, se isso for tranquilizador, as coisas parecerão cada vez mais previsíveis à medida que você passa algum tempo no mundo do 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 para a instalação completa no sistema. É por isso que eles são fornecidos com um sistema de compilação incorporado, uma coleção de scripts para fazer o necessário.

No mundo Linux / Código Aberto / Software Livre, um sistema de build teve uma adoção mais ampla: o GNU Autotools . Se você lida com um pacote de código-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 (também costuma verificar 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

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

Responda à atualização na pergunta

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

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

• No meu sistema, reservo /usr/local/binos pacotes instalados pelo meu gerenciador de pacotes. Tudo o que eu compilar / instalar manualmente entra /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 para o ambiente de área de trabalho que você está usando. Se funcionar para o seu sistema, ótimo. Mas não pode ser generalizado para todos os ambientes disponíveis no Unix.

• /usr/local/bintem a vantagem de já estar no seu caminho . Se você quiser usar outro diretório (como /opteu sugiro), não deixe de incluí-lo no seu PATH. Se você não souber 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

Eu acho que você tem que esclarecer com você mesmo o que você quer "registar"-lo com .

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

Você menciona várias distribuições diferentes. Às vezes, construo software a partir da fonte, mesmo que esteja disponível no repositório, porque quero que algumas opções de configuração sejam definidas no binário de distribuição. O único problema que tenho com isso é que, se o pacote é um pré-requisito para outra coisa, eu realmente tenho que registrá-lo no sistema de empacotamento para evitar a instalação acidental do pacote de distribuição sobre o que eu construí. Nos sistemas baseados no 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 preguiçoso - parece haver uma maneira melhor de fazer isso, criando um pacote fictício que pretende cumprir qualquer pré-requisito. Esse é o tipo de sugestão do m0nhawk de realmente criar um pacote a partir da fonte .tar.gz - exceto um pouco mais simples (vou ser sincero e dizer que não gosto da sugestão do m0nhawk).

Parece que você tem outros problemas além do do sistema de empacotamento. Não está claro para mim o que são, embora você mencione o ambiente da área de trabalho (por exemplo, Gnome). Eles são heterogêneos, portanto, simplesmente não há uma resposta para a pergunta "como faço isso no linux" - nem sequer é uma questão de "como faço isso no ubuntu" ou "como faço isso no linux" gentoo "- é uma questão de" como faço isso para a área de trabalho do gnome "ou" como faço isso na área de trabalho do XFCE ", etc. Na minha opinião, a única questão é a questão dos lançadores mencionados, que eu gostaria de acreditar que todo DE fornece um meio simples de fazer isso (mas não será exatamente o mesmo, porque eles são diferentes).

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

• o sistema de embalagem, por exemplo, apt ou yum
• o sistema init, por exemplo, systemd ou upstart
• o ambiente de desktop, por exemplo, kde ou unity
• o filebrower, por exemplo, nautilus ou konqueror
• ?????

Parte do motivo pelo qual não pode haver uma solução unificada simples (embora o padrão XDG possa fornecer algumas partes) é que "linux" não é um sistema operacional unificado simples e imagino que a grande maioria de seus usuários prefira dessa maneira. Geralmente não uso DE, e nunca uso o navegador de arquivos que ele acompanha, etc.

Mais uma vez, estou realmente tentando ser útil com isso e não apenas pontificar: se houver problemas que você deseja resolver aqui, terá que considerar com mais precisão quais são esses problemas e qual software está realmente envolvido com eles (além do "linux" ") se você quiser resolvê-los.

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 que algo seja executado. 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 dos seus ambientes. Pode ficar um pouco mais complexo com bibliotecas vinculadas e assim por diante, mas normalmente você não precisa ir tão longe.

Diferentes distribuições do Linux padronizaram em vários layouts de sistema de arquivos e sistemas de gerenciamento de pacotes, aí está o problema. Os Redhats usam rpm , Debians / Ubuntu usam pacotes deb. Arch seguiu seu próprio caminho também. 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 está inteiramente em uma distribuição ou um produto comercial que visa facilitar a instalação para todos, provavelmente são os únicos pontos que você começa a criar vários pacotes.

De fato, um arquivo tar.gz de origem construído com gccprovavelmente é a melhor definição de um "pacote Linux" comum. Um kernel Linux com alguns utilitários GNU e GCC praticamente o denominador comum entre todos os diferentes tipos de sistemas operacionais baseados em Linux que você pode obter.

Eu não chegaria ao ponto de dizer que "tão poucas" coisas estão disponíveis como pacotes porque algo específico que você está procurando não está. (ou talvez o distribuidor tenha optado por não se preocupar com todo esse barulho de pacote? Como o Chrome e seu próprio processo de atualização). Não são tão muitos pacotes de volta para tão muitos diferentes pacotes sistemas para muitas arquiteturas de software tanto livre seu não engraçado .

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

Existem vários guias na web sobre a criação de pacotes . O Debian é 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 é?

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

Obviamente, quando você coloca coisas nas contrapartes do "diretório inicial", elas não aparecem para outros usuários.

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

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