2010-06-08 17 views
1

J'ai lu page après page les avantages de l'utilisation du programme d'installation de paquets YUM et comment NOBODY devrait construire des installations à partir de fichiers sources (ce qui n'a toujours aucun sens), mais les dépôts et les sources compilent toujours les fichiers au format Tarball. Laisser une TON de travail (qui finit généralement par aller mal) à l'individu au lieu de mettre en forme des SRPM pour l'utilisateur final.Pourquoi les techniciens recommandent-ils l'installation de YUM, alors que les dépôts et les fournisseurs sont en retard?

Le monde est-il devenu fou? J'ai l'impression de prendre des pilules folles!

Répondre

0

Il y a quelques raisons d'utiliser une infrastructure d'emballage (comme miam):

  1. Création « installations » est beaucoup plus facile à faire, en raison de l'installation automatique des dépendances. Du simple

    yum install blah
    à la création de chroots avec mock/- installroot, ou des CD live, etc.

  2. Gestion de ces installations. De l'évident

    yum update
    à des opérations qui sont beaucoup plus difficile à faire autrement, comme:
    yum --security update
    ,
    yum --bz=1234 update-minimal
    ,
    yum --disablerepo=testing distro-sync
    .

  3. Vérification de ces installations. Les exemples évidents ici étant

    yum history
    (non disponible dans RHEL-5 atm simple) et
    yum verify
    .

... mais vitesse est pas un facteur, par exemple Fedora Rawhide se déplace aussi vite que gentoo.

RHEL-5 ne bouge pas si vite, parce qu'il a 3 ans et qu'il n'est pas censé casser ... pas parce qu'il est géré avec yum/rpms. Il existe des fournisseurs tiers, tels que iuscommunity, qui publient des versions plus récentes co-installables pour divers packages. Ou si vous avez besoin de créer votre propre.

Ou vous pouvez exécuter un serveur de production sur Fedora rawhide ou gentoo, les deux auront les derniers paquets très rapidement ... Je ne recommanderais pas cette option cependant.

-1

, entre autres, tarballs sont système indépendant et YUM semble être basé sur RPM et donc la plupart du temps utilisable par Linux uniquement (plus Netware et AIX, donc comme je le disais, Linux uniquement :))

+0

-1 pourquoi ????????? – DVK

1

Eh bien, d'abord De tous, il y a plus que RPM et YUM. Un SRPM serait (un peu) inutile à Debian, par exemple. Pour ce qui est de savoir pourquoi vous utiliseriez un référentiel de paquetages plutôt que de tout construire vous-même, je ne sais pas pour vous, mais je préfère courir (j'utilise Ubuntu pour avoir apt-get au lieu de miam):

# apt-get install firefox 

que d'essayer de comprendre toutes les dépendances, ainsi que toutes les dépendances dépendances, assurez-vous que je les versions correctes de tout, télécharger/construire/installer que je ne avoir (ou sont périmés: si vous mettez à jour des dépendances existantes, assurez-vous que les nouvelles versions ne cassent aucun logiciel existant et assurez-vous que je ne me retrouve pas avec 15 versions différentes de la même chose), et seulement après tout t chapeau puis télécharger/configurer/construire/installer firefox.

Puis réaliser que je veux aussi Open Office ou MySQL et recommencer à zéro! Cela dit, il existe certains paquets que j'installe la dernière version de source. Par exemple, j'exécute mon centre média en MythTV et j'aime toujours créer la dernière version de Subversion. Mais même alors, avec un gestionnaire de paquets, qui est aussi simple que:

# apt-get build-dep mythtv 
> cd ~/src/mythtv/ 
> svn co <svn repo of mythtv> 
> configure && (etc) 

C'est, le logiciel de gestion des paquets connaît déjà toutes les dépendances pour MythTV et il peut les télécharger et les installer automatiquement. Pourquoi passer des heures à tout suivre manuellement? En fin de compte, il me semble que vous préfèreriez peut-être une distribution comme Gentoo ... c'est l'avantage de Linux, bien sûr. Si vous n'aimez pas comment les choses fonctionnent dans la distribution Fedora/RedHat, vous pouvez en choisir une autre.

+0

merci pour votre contribution. Cela ne me permet toujours pas de contourner mon point de départ, qui est les dates de publication PAINFULLY retardé pour les paquets. CentOS, bien que stable, choisit toujours d'utiliser PHP 5.2.6 (très obsolète et rempli de bogues pour ne pas mentionner non-pci) et il vient de sortir en mai dernier. – JM4