Comment vraiment installer un fichier tar.gz sur Linux - comment gérer les applications installées manuellement (ou autonomes)?


12

Je vois tous ces liens expliquant les packages et les .debs ... Je le sais ... et il y a beaucoup de contraintes pour faire fonctionner les fichiers tar.gz (par exemple: update-alternatives pour Java ou déposer manuellement le fichier dans / usr / local / bin (ou ailleurs, que j'avais déduit d'heures de recherche)). Si les packages sont si intelligents, comment si peu d'applications Linux sont-elles disponibles dans les packages ou .debs / rpms?

Je parle en tant que nouvel utilisateur; Je sais que les experts le savent probablement mieux (je pense que je peux télécharger une version compilable d'Eclipse?). Comme netbeans et chrome .sh, eclipse est un répertoire simple et lancable, Java nécessite cette update-alternativesactivité mais je ne pense pas qu'il s'enregistre dans la "liste des programmes" d'Ubuntu / Debian (s'enregistre simplement en tant que commande), etc. (je sais que ce sont parfois disponible dans les référentiels, mais je ne comprends pas pourquoi les pages de téléchargement n'ont pas d'explications appropriées).

En bref: si vous téléchargez ou compilez un fichier tar.gz, comment l'enregistrer sur le système? update-alternativessemble l'enregistrer comme une commande, dans Ubuntu, il n'apparaît pas dans la barre de recherche. Dans Debian, je peux ajouter manuellement un raccourci vers le lanceur GNOME 2. Mais que dois-je vraiment faire?


Éditer:

Donc après avoir joué un peu plus avec les nouvelles solutions, je peux en quelque sorte affiner mon "problème":

Comment dois-je gérer mes programmes installés manuellement? Firefox et Eclipse sont mes seuls exemples à ce jour (je ne télécharge pas beaucoup de choses). Ils peuvent tous deux sortir de la boîte, ce que j'aime. Sauf, où dois-je les installer? Je vois qu'Eclipse a ses propres instructions, mais je préfère faire tous mes "packages manuels" de la même manière.

  1. Après quelques recherches, j'ai décidé de mettre ces programmes en place /usr/local/bin.
  2. De la façon d'installer eclipse , j'ai pensé à obtenir quelque chose à afficher dans le lanceur, je dois mettre un xxx.desktopfichier ~/.local/share/applications/. Le nom de ce fichier .desktop est-il important?
  3. Les trucs avec les autotools (je cherche un configureou un unix/configurefichier) fonctionneront bien. Quelques points de recherche que je devrais utiliser CheckInstallpour garder une trace de tout cela.
  4. Je devrais utiliser update-alternativespour enregistrer des chemins. À partir de ce fil java , il semble que je crée un lien de /usr/bin/javaà /usr/lib/jvm/jdk.... Lorsque j'installe ces applications "autonomes" comme Eclipse ou Firefox, dois-je toujours créer un lien vers /usr/bin/[app]? Et si l'assertion 1 est vraie, je ferais des trucs commesudo update-alternatives --install "/usr/bin/[app]" "[app]" "/usr/local/bin/[app]" 1

Ces instructions sont-elles correctes / un bon moyen de gérer les installations manuelles? Y a-t-il d'autres étapes à suivre? D'autres suggestions?


1
Pourquoi ne pas chercher un *.debforfait à la place?
m0nhawk

@ m0nhawk Vous ne trouvez pas toujours un fichier .deb? Comme sur la page de téléchargement d'Eclipse, c'est juste tar.gz. Sauf si je le manque complètement
Raekye

1
Pour Eclipse, il existe définitivement un paquet pour Debian ( pour Ubuntu ). Et je pense que la meilleure façon de gérer le *.tar.gzlogiciel est de créer le package approprié: *.rpm, *.debetc.
m0nhawk

1
Vous avez besoin d'un .desktopfichier pour que quelque chose apparaisse dans le menu. update-alternativesne fonctionne que pour prioriser votre PATH.
tripleee

1
Votre question porte toujours sur "que dois-je faire pour enregistrer un nouveau logiciel avec ______" où _____ est un environnement de bureau particulier, et non "que dois-je faire WRT linux" en général. De plus, peut-être, une ignorance implicite concernant la variable d'environnement $ PATH?
goldilocks

Réponses:


15

Pourquoi de nombreuses applications ne sont-elles pas disponibles dans les référentiels de packages?

Il peut y avoir plusieurs raisons:

Il n'y a pas une seule raison. Si vous souhaitez voir votre application préférée dans le gestionnaire de paquets de votre distribution, vous devez traiter chaque cas séparément. Essayez de contacter les développeurs (sur un canal IRC ou une liste de diffusion par exemple) et demandez comment vous pourriez aider à l'emballage.

Comment installer une archive tar?

Une archive tar (package .tar.gz) peut contenir n'importe quoi. Jusqu'à ce que vous l'ouvriez, vous n'avez aucun moyen de supposer comment l'installer. Encore une fois, chaque paquet doit être abordé différemment.

Cherchez de la documentation! Tout package (semi-) décent fournira des instructions sur la façon d'installer l'application. Votre premier réflexe devrait toujours être de rechercher un fichier texte appelé README, INSTALL ou quelque chose comme ça. La consultation du site Web de l'éditeur peut également être utile.

Étant donné que chaque package est différent, il n'existe aucun moyen universel de traiter toutes les archives tar dans le monde. C'est comme demander une recette qui fonctionne avec tous les ingrédients du monde. N'arrive pas.

Une bonne connaissance de votre système, de votre distribution et de votre environnement de bureau vous aidera, donc si cela est rassurant, les choses seront de plus en plus prévisibles à mesure que vous passerez du temps dans le monde Linux.

Un cas particulier: Autotools

À mesure que les projets grossissent, ils doivent fournir des moyens faciles de passer du code source au binaire pour une installation complète sur le système. C'est pourquoi ils sont livrés avec un système de construction intégré, une collection de scripts pour faire le nécessaire.

Dans le monde Linux / Open Source / Logiciel libre, un système de build a été adopté plus largement: GNU Autotools . Si vous avez déjà affaire à un package source (n ouvert), il y a de fortes chances que vous utilisiez Autotools.

Dans le cas le plus simple, voici comment installer une application empaquetée avec des outils automatiques:

  • ./configure: Un script qui va générer les Makefiles correspondant à votre système (il vérifie aussi souvent la disponibilité des dépendances).
  • make: Compilation du code source selon les Makefiles générés précédemment.
  • make install: Copie les fichiers binaires aux emplacements appropriés, crée des liens symboliques et toute autre étape définie par le développeur.

Remarques

  • configureles scripts ont généralement beaucoup d'options, comme le compilateur à utiliser ou comment définir le répertoire cible. Si vous avez besoin de flexibilité, cela vaut la peine de regarder ./configure --help.
  • Même si vous êtes sûr qu'il s'agit d'Autotools et que vous le savez très bien, commencez toujours par lire les documents (LISEZMOI, INSTALLER, ...)

Répondre à la mise à jour dans la question

Ce que vous demandez n'a pas de réponse définitive. Tout le monde ici pourrait avoir une opinion sur ce qui constitue une "bonne pratique", mais à la fin de la journée, vous seul pouvez trouver ce qui fonctionne pour vous . S'il y avait une réponse facile, vous ne poseriez pas la question. Votre distribution aurait répondu pour vous.

Cela étant dit, voici quelques remarques personnelles.

  • Sur mon système, je réserve /usr/local/binles packages installés par mon gestionnaire de packages. Tout ce que je compile / installe à la main entre /opt. Ceci est un détail mais il permet d'éviter les maux de tête majeurs lors de l'utilisation de plusieurs versions du même programme.

  • xxx.desktopet les problèmes d'interface graphique en général sont spécifiques à l'environnement de bureau que vous utilisez. Si cela fonctionne pour votre système, tant mieux. Mais il ne peut pas être généralisé à tous les environnements disponibles sur Unix.

  • /usr/local/bina l'avantage d'être déjà dans votre PATH . Si vous souhaitez utiliser un autre répertoire (comme /optje le suggère), assurez-vous de l'inclure dans votre PATH. Si vous ne savez pas comment le faire, ouvrez un terminal et exécutez ce qui suit dans un terminal (pas la plus jolie façon de le faire, mais sans rien savoir de votre système, je ne peux rien suggérer d'autre):echo 'export PATH=$PATH:/opt' >> ~/.bashrc


Merci pour la réponse détaillée. J'ai regardé les fichiers Lisezmoi, mais j'ai décidé que je ne voulais pas faire quelque chose de différent à chaque fois. Donc, après beaucoup plus de recherches, de tentatives et de frustration, j'ai trouvé une question / spécification plus concrète - voir l'article mis à jour.
Raekye

Je vous en prie, j'espère que cela aide :) J'ai modifié ma réponse pour répondre à vos mises à jour. Gardez à l'esprit qu'il n'y a pas de "One True Way" pour faire les choses (sauf si vous êtes un emacsutilisateur). Vous devez passer par des essais et des erreurs pour apprendre, avec le temps, les avantages et les inconvénients de chacune des différentes approches.
rahmu

Merci pour la mise à jour! Certainement. Je suppose que cela xxx.desktopfonctionne généralement pour GNome. Que savez-vous sur l'utilisation update-alternativespour définir le chemin?
Raekye

1
Pour autant que je sache, c'est une façon spécifique à Debian de gérer les logiciels génériques, comme avoir plusieurs navigateurs ou éditeurs. (Ubuntu et Mint sont basés sur Debian et en ont hérité). Voici plus si vous êtes intéressé
rahmu

Très bonne réponse. Une chose qui est souvent nécessaire (ou du moins préférée) est de faire une sudo make install comme dernière étape (avec un paquet en qui vous avez confiance). Cela donne au processus les autorisations dont il a besoin pour placer des choses dans des répertoires système qui n'appartiennent pas à votre utilisateur (comme / usr / bin).
Joe

8

Je pense que vous devez clarifier avec vous - même ce que vous voulez « enregistrer » ce avec .

Pour expliquer - et je n'essaie pas d'être intelligent - "linux" est, bien sûr, le noyau, et le noyau ne connaît ni n'a aucun intérêt pour aucun des logiciels de l'espace utilisateur sur votre système au-delà d'init. Alors de quoi parle-t-on ici?

Vous mentionnez un certain nombre de distributions différentes. Je crée parfois des logiciels à partir des sources, même s'ils sont disponibles dans le référentiel, car je veux des options de configuration définies qui ne sont pas définies dans le binaire de distribution. Le seul problème que j'ai avec cela est que si le package est une condition préalable à autre chose, je dois en effet l'enregistrer avec le système de package afin d'éviter d'installer accidentellement le package de distribution au-dessus de celui que j'ai construit. Sur les systèmes basés sur fedora / rpm, cela se fait avec rpm -i --justdb <package>. Je ne fais pas cela sur les systèmes basés sur debian / apt; à la place, je force les installations au besoin, ce qui est peut-être paresseux - il semble y avoir une meilleure façon de le faire, en créant un package factice qui prétend remplir toutes les conditions préalables. C'est un peu dans la ligne de la suggestion de m0nhawk de créer réellement un paquet à partir de la source .tar.gz - sauf un peu plus simple (je vais être honnête et dire que je n'aime pas du tout la suggestion de m0nhawk).

Il semble que vous ayez d'autres problèmes en plus de celui du système d'emballage. Ce n'est pas clair pour moi, bien que vous mentionniez l'environnement de bureau (par exemple, Gnome). Celles-ci sont hétérogènes, il n'y a donc tout simplement pas de réponse unique à la question, "comment puis-je faire cela sur linux" - il ne s'agit même pas de "comment faire cela sur ubuntu" ou "comment dois-je faire cela sur gentoo "- il s'agit de" comment faire cela pour le bureau gnome "ou" comment faire cela sur le bureau XFCE ", etc. À mon avis, le seul problème est la question des lanceurs que vous mentionnez, que je aimerait croire que chaque DE fournit un moyen simple de le faire (mais ce ne sera pas exactement le même, car ils sont différents).

Ensuite, il y a les services, qui sont gérés par le système init (par exemple, systemd ou upstart). Cette question est donc en fait une série de questions connexes concernant, potentiellement:

  • le système d'emballage, par exemple apt ou yum
  • le système init, par exemple, systemd ou upstart
  • l'environnement de bureau, par exemple, kde ou unité
  • le classeur, par exemple, nautilus ou konqueror
  • ?????

Une partie de la raison pour laquelle il ne peut pas y avoir une solution unifiée simple (bien que la norme XDG puisse en fournir certaines parties) est que "linux" n'est pas un système d'exploitation unifié simple et j'imagine que la grande majorité de ses utilisateurs le préfèrent de cette façon. Souvent, je n'utilise pas du tout un DE, et je n'utilise jamais le navigateur de fichiers fourni, etc.

Encore une fois, j'essaie vraiment d'être utile avec cela et pas seulement de pontifier: s'il y a des problèmes que vous voulez résoudre ici, vous devrez considérer plus précisément quels sont ces problèmes et quels logiciels sont réellement impliqués avec eux (au-delà de "linux"). ") si vous voulez les résoudre.


"dans la distribution binaire" <- / moi marmonne quelque chose à propos des distributions basées sur la source
njsg

De plus, un problème avec la norme XDG est probablement que certains amonts ne s'en soucient pas du tout et que les développeurs de distribution sont ceux qui fournissent leurs .desktopfichiers, pour ce type de tâches, celles-ci sont requises.
njsg

Je ne sais pas si les développeurs en amont devraient s'en préoccuper. Je viens de mentionner XDG car il est disponible pour l'utilisateur final si vous souhaitez l'utiliser. Un prix de l'hétérogénéité est qu'il impose inévitablement à l'utilisateur un fardeau de responsabilité qu'il n'aurait pas avec OSX, par exemple. Certaines distributions Linux visent à minimiser cela plus que d'autres, et vous êtes libre de choisir, mais en fin de compte, je pense que les gens qui sont vraiment mal à l'aise avec ce modèle ne devraient tout simplement pas utiliser Linux du tout - je ne sais pas pourquoi ils voudraient la première place, en fait.
goldilocks

J'ai en quelque sorte formulé une meilleure question - comment gérer mes applications installées manuellement? Comme Eclipse et Firefox, qui fonctionnent généralement sans dépendances complexes (je peux donc le configurer moi-même et télécharger le package). Ils fonctionnent de manière autonome, comme votre ou quelqu'un d'autre l'a mentionné, mais devrais-je garder une trace de ces applications, au lieu de les laisser tout autour de mon système de fichiers? (Voir la question mise à jour)
Raekye

Raekye: Cela ne fait aucune différence pour moi, c'est que vous n'avez rien à faire pour gérer ou "garder une trace" des choses que vous avez installées à partir de la source dans / usr / local, sauf dans la mesure où vous le souhaitez pour quels que soient vos objectifs. Au-delà de la compilation et de l'installation dans $ PATH, il n'y a pas de registre Linux universel car il n'y a pas de raison pour une telle approche universelle. Je suppose que vous craignez juste d'avoir raté quelque chose - vous ne l'avez pas fait. Vous dé-tarez, vous configure, vous make install. Voilà, c'est fait. Tout ce qui suit est une question de préférence personnelle.
goldilocks

5

Je pense que la raison fondamentale de votre problème global est qu'un système Linux ne contient pas en soi de "registre" en tant que tel. Un fichier exécutable est tout ce dont vous avez vraiment besoin pour exécuter quelque chose. Si vous ne souhaitez pas spécifier le chemin d'accès complet à l'exécutable, la plupart des shells les rechercheront dans les répertoires répertoriés dans la variable $ PATH de votre environnement. Cela peut devenir un peu plus complexe avec les bibliothèques liées et ainsi de suite, mais normalement vous n'avez pas besoin d'aller plus loin.

Différentes distributions de Linux se sont normalisées sur diverses configurations de systèmes de fichiers et systèmes de gestion de paquets, c'est là que réside le problème. Les Redhats utilisent rpm , Debians / Ubuntu utilisent les packages deb. Arch a également suivi sa propre voie . Du point de vue des projets logiciels, à moins que vous ne vouliez être inclus dans une distribution, votre base d'utilisateurs est entièrement dans une distribution, ou un produit commercial qui vise à faciliter l'installation pour tout le monde, ce sont probablement les seuls points que vous commencez à chercher à construire divers forfaits.

En fait, un tar.gz source qui construit avec gccest probablement la meilleure définition d'un "paquet Linux" commun. Un noyau Linux avec certains utilitaires GNU et GCC à peu près le dénominateur commun entre toutes les différentes versions de systèmes d'exploitation basés sur Linux que vous pouvez obtenir.

Je n'irais pas jusqu'à dire que "si peu" de choses sont disponibles sous forme de packages parce que quelque chose de spécifique que vous recherchez ne l'est pas. (ou peut-être que le distributeur a choisi de ne pas s'embêter avec tout ce tapage? Comme Chrome et son propre processus de mise à jour). Il y a tellement de nombreux paquets autour de si nombreux différents forfaits systèmes pour tant d'architectures pour le logiciel libre tant son pas drôle .

Si vous avez construit quelque chose qui n'est pas fourni en tant que package pour votre distribution de Linux, ou prend en charge l'option de génération en tant que package, la meilleure façon de "l'enregistrer" comme un vrai package est de construire un package pour lui, en définissant où tous les fichiers doivent être basés sur le système de package que vous choisissez et l'installer de cette façon. Soyez une âme et apportez votre travail d'emballage au projet afin que d'autres puissent en bénéficier.

Il existe différents guides sur le Web sur la création de packages . Debian en fait partie .

Si tout ce que vous voulez faire est d'exécuter un package compilé, ajoutez peut - être le chemin binaire à votre $PATH?

Si vous faites autre chose, c'est quoi?


"Si tout ce que vous voulez faire est d'exécuter un package compilé, ajoutez peut-être le chemin binaire à votre $ PATH?" <- Je suppose que toute procédure d'installation sensée (disons, make installou similaire) installerait à tout le moins un lien symbolique sous /usr/bin/, sinon installer le tout sous /)
njsg

Surtout, je suppose que c'est dû au fait que je fais beaucoup --prefix=/elsewherepour garder les builds personnalisés loin de l'arbre normal.
Matt

1
Généralement, les tarballs utilisant make installseront installés sur/usr/local/bin
Shadur

0

Je voudrais ajouter que vous pouvez également créer un lien symbolique vers ~/bin/au lieu de /usr/bin. *.desktoples fichiers peuvent être placés dans ~/.local/share/applications/ou /usr/share/applications/. Seulement, j'utilise mon ordinateur et j'aime éviter autant que possible de toucher moi-même les fichiers système (quoi que ce soit en dehors de mon répertoire personnel).

Bien sûr, lorsque vous placez des éléments dans les équivalents du "répertoire personnel", ils n'apparaissent pas pour les autres utilisateurs.

Voici ce qui est inclus dans la valeur ~/.profilepar défaut pour Debian Wheezy:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.