La manière dont Red Hat a choisi yum est bien documentée : ils ont pris tous les apt-like pour rpm de l'époque, fait un audit de code, et pris celui qui avait un code propre et extensible (et embauché son auteur). yum a gagné car :
1. il était codé proprement (pas encore optimisé, mais bien structuré). On peut optimiser du bon code, c'est très difficile de maintenir du code rapide mais bordélique
2. il utilisait le moteur de résolution de dépendances de rpm au lieu d'utiliser un algo différent lors de la résolution réseau, et espérer que rpm soit d'accord à l'installation (apt-rpm). Cela a permis :
a. de reprendre l'existant rpm sans rupture (simple bon sens pour Red Hat qui était n°1 sur son marché
b. d'écrire des règles de packaging rigoureuses, claires et détaillées, puisqu'il n'y a aucune ambiguïté sur le moteur de règles à respecter (tout passe par librpm et que par librpm), ce qui a permis d'assainir et améliorer la qualité de la distribution en général
3. il était intégrable simplement dans les autres outils Red Hat (Anaconda est en python, comme son nom l'indique). C'est complètement invisible pour les utilisateurs, mais aujourd'hui tous les outils Fedora/Red Hat (Anaconda, PackageKit, la ferme de compilation, Spacewalk, Satellite, Cobbler j'en passe et des meilleures) font appel à l'infrastructure yum et ça marche très bien.
Yum est un choix qui s'est révélé plus que judicieux avec le temps. Red Hat n'avait pas besoin d'un client d'installation type apt-rpm (ils avaient déjà leur propre bouse, up2date qui a heureusement été abandonnée) mais d'une vraie brique d'infrastructure avec laquelle ils pourraient construire d'autres applications. Le yum vu par l'utilisateur est juste un frontal shell, c'est une toute petite partie de ce que yum fait pour Fedora.
D'ailleurs Suse/Novell (qui avait aussi besoin de construire des infras autour de rpm) a écarté comme Red Hat tous les clients apt-like de l'époque, et a fini par écrire le sien de zéro. C'est ce qui leur a permis ensuite de construire https://build.opensuse.org/
[^] # Re: 6 mois d'utilisation déjà
Posté par nimnim . En réponse à la dépêche Sortie de Fedora 14. Évalué à 6.
1. il était codé proprement (pas encore optimisé, mais bien structuré). On peut optimiser du bon code, c'est très difficile de maintenir du code rapide mais bordélique
2. il utilisait le moteur de résolution de dépendances de rpm au lieu d'utiliser un algo différent lors de la résolution réseau, et espérer que rpm soit d'accord à l'installation (apt-rpm). Cela a permis :
a. de reprendre l'existant rpm sans rupture (simple bon sens pour Red Hat qui était n°1 sur son marché
b. d'écrire des règles de packaging rigoureuses, claires et détaillées, puisqu'il n'y a aucune ambiguïté sur le moteur de règles à respecter (tout passe par librpm et que par librpm), ce qui a permis d'assainir et améliorer la qualité de la distribution en général
3. il était intégrable simplement dans les autres outils Red Hat (Anaconda est en python, comme son nom l'indique). C'est complètement invisible pour les utilisateurs, mais aujourd'hui tous les outils Fedora/Red Hat (Anaconda, PackageKit, la ferme de compilation, Spacewalk, Satellite, Cobbler j'en passe et des meilleures) font appel à l'infrastructure yum et ça marche très bien.
Yum est un choix qui s'est révélé plus que judicieux avec le temps. Red Hat n'avait pas besoin d'un client d'installation type apt-rpm (ils avaient déjà leur propre bouse, up2date qui a heureusement été abandonnée) mais d'une vraie brique d'infrastructure avec laquelle ils pourraient construire d'autres applications. Le yum vu par l'utilisateur est juste un frontal shell, c'est une toute petite partie de ce que yum fait pour Fedora.
D'ailleurs Suse/Novell (qui avait aussi besoin de construire des infras autour de rpm) a écarté comme Red Hat tous les clients apt-like de l'époque, et a fini par écrire le sien de zéro. C'est ce qui leur a permis ensuite de construire https://build.opensuse.org/