Installer apt-get sur redhat
Est-il possible d'installer apt-get sur redhat? J'ai l'impression que vous ne pouvez pas, mais je voulais juste en être sûr. Si c'est possible, la vie serait BEAUCOUP plus facile lors de l'installation de divers programmes, notamment parce que yum n'a vraiment pas autant de programmes disponibles qu'il n'y paraît.
Voici ce que j'ai essayé (juste pour mémoire):
J'ai essayé d'installer apt-get en suivant ces instructions, mais redhat n'a pas de dpkg, donc je suis de retour à la case 1.
Je pose cette question car j'ai des difficultés à installer un plugin pour Pidgin (Pidgin-sipe) car yum install libglib2.0-dev échoue, ce qui me prouve qu'avoir apt-get pourrait être un investissement intéressant.
Aucune suggestion?
Vous n'avez pas besoin de remplacer votre outil de gestion de packages simplement parce qu'un package semble manquer.
Chaque outil de gestion de packages est étroitement intégré à sa distribution, et ce n'est pas différent avec CentOS. apt est bien intégré à Debian et ses dérivés, et même s'ils (Debian, Ubuntu, Mint, Knoppix ...) utilisent le même outil pour la gestion des paquets, leurs paquets sont liés et configurés avec des versions de paquets spécifiques qui dans certains cas, ne fonctionnera qu'avec les dépendances spécifiques de cette distribution.
Ce dont vous avez besoin est d'installer le package de développement de glib spécifique pour les systèmes d'exploitation similaires:
yum install glib2-devel.x86_64
La mise en garde ici est que vous devrez trouver un package équivalent, qui peut avoir un nom différent sur votre distribution. Savoir rechercher des packages sur la distribution que vous utilisez est un bon moment consacré aux connaissances.
Comment ai-je découvert que c'était le nom:
[root@ftp ~]# yum search glib2| grep dev
glib2-devel.i686 : A library of handy utility functions
glib2-devel.x86_64 : A library of handy utility functions
spice-glib-devel.i686 : Development files to build Glib2 applications with
spice-glib-devel.x86_64 : Development files to build Glib2 applications with
Et en affichant les informations sur le package, vous pouvez voir qu'il semble s'agir du même package de développement de bibliothèque:
[root@ftp ~]# yum info glib2-devel.x86_64
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.brisanet.com.br
* extras: centos.brisanet.com.br
* rpmforge-extras: apt.sw.be
* updates: centos.brisanet.com.br
Available Packages
Name : glib2-devel
Arch : x86_64
Version : 2.28.8
Release : 9.el6
Size : 300 k
Repo : base
Summary : A library of handy utility functions
URL : http://www.gtk.org
License : LGPLv2+
Description : The glib2-devel package includes the header files for the GLib library.
De plus, si vous n'êtes pas familier avec la recherche de packages, cet outil en ligne peut vous aider à trouver des packages sur les distributions Linux les plus courantes: Linux Packages Search
TL; DR apt ne fonctionne généralement pas avec les distributions basées sur Enterprise Linux et vous ne trouverez pas beaucoup de repos qui travailler pour vous de toute façon.
Si vous rencontrez des difficultés pour trouver le logiciel que vous souhaitez sur Red Hat, c'est parce que vos référentiels n'ont pas les packages. Ce que vous voulez examiner, c'est ajouter différents référentiels. Pour Red Hat Enterprise Linux, le premier dépôt à ajouter généralement est Extra Packages For Enterprise Linux (EPEL) hébergé chez The Fedora Project. Vous trouverez probablement BEAUCOUP de ce qui vous manque dans ce dépôt.
Plus d'informations:
Bien qu'il soit certainement possible d'installer les utilitaires de gestion des packages apt sur un système Enterprise Linux, cela ne signifie pas que vous pourrez faire tout ce que vous en aurez une fois que vous aurez terminé.
Le problème ici est que l'utilitaire apt est un programme qui fonctionne avec les répertoires publiés de packages logiciels (les référentiels sont le nom habituel pour moi, mais il peut varier). Yum, rpm, dnf, emerge, etc. sont tous des utilitaires pour varier les distributions * NIX qui font la même chose. Mais ils n'offrent pas le logiciel eux-mêmes, ils sont configurés pour interroger les référentiels et fournir des packages à partir d'eux. L'autre problème est que les référentiels courants que vous trouvez en ligne sont souvent créés et configurés pour fonctionner avec les utilitaires de gestion de packages natifs pour le système d'exploitation pour lequel ils proposent des logiciels. Vous pourriez probablement configurer apt sur votre système RHEL7 pour interroger les dépôts Debian, mais le logiciel serait probablement incompatible avec votre système en raison des différences dans la façon dont Debian et Red Hat construisent, mettent en page, structurent et configurent leur fonctionnement systèmes. C'est comme essayer d'installer le logiciel Mac OS X sur votre système Linux. Ils sont tous deux techniques * basés sur NIX, mais ils varient considérablement dans leur fonctionnement.
Je pose cette question parce que j'ai du mal à installer un plugin pour Pidgin (Pidgin-sipe) parce que yum install libglib2.0-dev échoue, ce qui est la preuve pour moi qu'apt-get pourrait être un investissement utile.
Réponse courte: pas vraiment, non.
Il y a un port de apt pour rpm, à savoir apt-rpm . Il était utilisable jusqu'à relativement récemment, mais pour autant que je sache, Red Hat et ses dérivés ne le prennent pas en charge, il se peut qu'il ne le soit plus maintenant. Le développement semble au point mort depuis 2008, ce qui n'est pas prometteur. Aussi, apt-rpm ne peut pas être utilisé avec les référentiels yum, donc cela n'est utile que si quelqu'un a construit des référentiels rpm qui peuvent être utilisés avec apt.
Il y avait aussi une variante appelée apt4rpm créée par Connectiva, mais qui semble avoir été encore moins utilisée que apt-rpm.
Installer le propre apt de Debian sur un système Red Hat est une perte de temps, même s'il s'installe avec succès. dpkg est disponible pour Red Hat, ou du moins il l'était. Mais essayer de mettre en place un système parallèle de type Debian en utilisant dpkg et apt serait un non-démarreur complet, je pense.
Je me souviens avoir utilisé apt-rpm sur un système Red Hat vers 2006 pour l'administration système de base. Si la mémoire est bonne, c'était une installation CentOS. Cela fonctionnait encore assez bien à l'époque. Mais nous sommes en 2017, et je suppose que apt-rpm est désormais mort.
Dans tous les cas, je doute que l'utilisation de apt sur un système Red Hat, même s'il était disponible et fonctionnel, ferait une grande différence dans votre expérience. La raison pour laquelle apt fonctionne bien sur Debian et ses dérivés n'est pas due à la qualité magique de apt. C'est principalement à cause du célèbre contrôle de la qualité de Debian, bien que les outils de gestion de paquets Debian (dpkg, apt etc.) peuvent être à l'origine d'une bonne conception et mise en œuvre.
Si vous voulez "l'expérience apt", utilisez Debian.
Il est possible de le faire, mais très difficile, généralement déconseillé et presque certainement inutile.
Ce que vous avez demandé, c'est comment installer le système de gestion de paquets Debian sur un système Red Hat.
Le système de gestion des packages suit les packages installés dans un système, ce qui facilite l'installation et les mises à jour des packages, suit les dépendances et évite les conflits entre les packages. En particulier pour les deux dernières raisons, différents systèmes de gestion de paquets sont fondamentalement incompatibles entre eux; essayer d'utiliser deux systèmes différents simultanément, sans supervision très attentive, rendra rapidement votre système inutilisable, car vous tenteriez effectivement d'installer deux distributions Linux différentes l'une sur l'autre.
Lorsque l'on mappe l'arbre généalogique des distributions Linux, le point de branchement principal est le choix du système de gestion des packages. Les deux systèmes les plus courants sont le système de gestion de paquets Debian, DPKG, et le système de gestion de paquets Red Hat, RPM. "apt-get" est un frontal pour utiliser le système DPKG, et il nécessite le reste de l'ensemble d'outils pour fonctionner; de même, "yum" est un frontal pour l'utilisation du système RPM.
Il est parfois possible de convertir un package d'un système à l'autre. alien est une application pour ce faire. Notez qu'il n'est presque jamais mentionné sans avertir qu'il n'est pas fiable.
Si le problème que vous souhaitez résoudre est que vous souhaitez installer une application spécifique sur un système Red Hat, vous pouvez trouver qu'il est préférable d'utiliser un package d'une autre distribution Linux qui utilise RPM; rpmfind peut vous aider à rechercher. Il est légèrement plus fiable de trouver un RPM source et de le reconstruire sur votre système; cela réduit la probabilité de problèmes avec les dépendances sur des binaires compilés spécifiques. Vous pouvez également contourner la gestion des packages en trouvant l'archive tar source de l'application et en la compilant.
Si le problème que vous souhaitez résoudre est d'avoir plus de packages disponibles en général, alors vous devez garder à l'esprit que Red Hat Enterprise Linux, par conception, met l'accent sur la stabilité, et ses référentiels officiels sont relativement limités. Vous préférerez peut-être utiliser Fedora Linux, étroitement lié, qui a une sélection beaucoup plus large de paquets dans ses référentiels officiels, ou vous pouvez passer à Debian ou à l'un de ses dérivés.
Comme d'autres personnes l'ont dit dans les réponses ci-dessus, les distributions et la gestion de leurs packages sont étroitement liées. Si vous devez installer des éléments à partir de dépôts Debian ou Ubuntu dans votre distribution basée sur RPM, je pense que votre meilleur pari est de configurer un chroot correspondant (via debootstrap) et d'installer tout ce dont vous avez besoin là-dedans. Vous aurez alors essentiellement une Debian fonctionnant "à côté" de votre distribution.
Vous pouvez ensuite configurer des liens symboliques et/ou des scripts qui exécutent n'importe quelle application que vous avez installée à partir du chroot - et cela fonctionne également pour les applications graphiques. Je l'ai fait pour des raisons de sandboxing avec diverses applications, mais la vôtre est également une raison valable. Un Debian dans un conteneur Docker est une option similaire que vous pouvez essayer - en gros, un chroot en bac à sable bien meilleur.