> je passe sur le côté perl, décidément tu fais vraiment dans la mauvaise foi... (ou alors c'était un pauvre lancé de troll...)
OK, c'était facile. M'enfin Perl ce n'est pas ce qu'il y a de plus propre.
> Le problème c'est que chaque distribution fait un peu à ca sauce et ne veut jamais reprendre les outils d'une autre...
Fedora a repris l'outils de Yellow Dog. Yum a été fait pour Yellow Dog à l'origine, pas pour Fedora.
> Et pourquoi redhat/fedora n'a pas voulu prendre urpmi ?
La raison est simplement que personne ne l'a proposé ! Des gens ont proposé apt, smart et yum, mais urpmi n'a jamais été proposé. C'est la principale raison.
Donc, je ne peux pas dire que urpmi a été refusé pour telle ou telle raison technique. Il n'y a pas eu de débat sur urpmi. C'est tout.
NB : Personne n'a proposé urpmi via Fedora Extras (Fedora Extras n'avait pas à l'accèpter, puisque ça n'a même pas été proposé).
S'il devait y avoir une raison technique, le fait que urpmi utilise Perl n'est pas en sa faveur car Red Hat/Fedora est très Python (tous les outils de configuration de Fedora sont en Python). Notons que smart utilise aussi python ce qui était un argument de poid en sa faveur. Ce qui n'est pas apprécié dans smart, c'est sa résolution de dépendance. Smart peut downgrader un paquet pour en installer un autre. C'est une de ses qualités mais Fedora ne veut surtout pas ça. Il était aussi reproché à smart de ne pas utiliser librpm pour la résolution de dépendance.
> - il y a smart et apt dans fedora car up2date sucks
Admettons. Red Hat/Fedora a vu que ça sucks et passe à autre chose. Où est le problème ?
Mandriva peut-il en faire de même avec urpmi ? Ce n'est pas ce qu'on voit.
Quand up2date est sorti, il y avait quoi pour rpm ? Pratiquement rien (sauf peut-être urpmi). up2date est sorti avec RH7.0. Il devait être en gestation bien avant RH7.0 car up2date a été fait spécifiquement pour Red Hat Network et ne supportait que Red Hat Network. A la sortie de FC1, up2date c'est vu ajouter les dépôt apt, yum et rpm (un répertoire avec des paquets rpm). Ce qui montre qu'à l'époque de FC1, up2date devait rester pour longtemps dans Fedora. L'arrivée de Yum n'était pas prévu. Mais Yum a été proposé et il a été considéré qu'il était meilleur qu'up2date. Aujourd'hui up2date a été viré de Fedora et RHEL, pour RHEL5 qui sort début mars. Pour RHEL 5, Yum peut utiliser le protocole Red Hat Network.
> et qu'il fallait bien quelque chose de potable avant qu'ils réinventent la roue avec yum
Yum ne réinvente pas la roue.
- Yum est en python et Red Hat/Fedora utilise beaucoup Python. C'est le seul gestionnaire de paquet qui utilise Python avec Smart. L'installeur de Fedora, system-config-package, firstboot, etc utilise Python. Yum étant en Python, il s'integre à ces derniers sans problème.
- Yum utilise rpm-python au-lieu de réinventer la roue (rpm-python a été fait entre autre pour Anaconda)
- Yum utilise librpm pour résoudre les dépendance au-lieu de réinventer la roue. Tous les autres gestionnaires de paquet font la résolution de dépendance eux même et ce sont eux qui réinvente la roue.
- Pour vérifer l'installation/mise à jour/suppression de paquets (conflit de fichiers typiquement), Yum joue une transaction rpm "classique".
La dernier chose que fait yum, c'est de réinventer la roue.
[^] # Re: Autre temps, autre moeurs...
Posté par IsNotGood . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 1.
OK, c'était facile. M'enfin Perl ce n'est pas ce qu'il y a de plus propre.
> Le problème c'est que chaque distribution fait un peu à ca sauce et ne veut jamais reprendre les outils d'une autre...
Fedora a repris l'outils de Yellow Dog. Yum a été fait pour Yellow Dog à l'origine, pas pour Fedora.
> Et pourquoi redhat/fedora n'a pas voulu prendre urpmi ?
La raison est simplement que personne ne l'a proposé ! Des gens ont proposé apt, smart et yum, mais urpmi n'a jamais été proposé. C'est la principale raison.
Donc, je ne peux pas dire que urpmi a été refusé pour telle ou telle raison technique. Il n'y a pas eu de débat sur urpmi. C'est tout.
NB : Personne n'a proposé urpmi via Fedora Extras (Fedora Extras n'avait pas à l'accèpter, puisque ça n'a même pas été proposé).
S'il devait y avoir une raison technique, le fait que urpmi utilise Perl n'est pas en sa faveur car Red Hat/Fedora est très Python (tous les outils de configuration de Fedora sont en Python). Notons que smart utilise aussi python ce qui était un argument de poid en sa faveur. Ce qui n'est pas apprécié dans smart, c'est sa résolution de dépendance. Smart peut downgrader un paquet pour en installer un autre. C'est une de ses qualités mais Fedora ne veut surtout pas ça. Il était aussi reproché à smart de ne pas utiliser librpm pour la résolution de dépendance.
> - il y a smart et apt dans fedora car up2date sucks
Admettons. Red Hat/Fedora a vu que ça sucks et passe à autre chose. Où est le problème ?
Mandriva peut-il en faire de même avec urpmi ? Ce n'est pas ce qu'on voit.
Quand up2date est sorti, il y avait quoi pour rpm ? Pratiquement rien (sauf peut-être urpmi). up2date est sorti avec RH7.0. Il devait être en gestation bien avant RH7.0 car up2date a été fait spécifiquement pour Red Hat Network et ne supportait que Red Hat Network. A la sortie de FC1, up2date c'est vu ajouter les dépôt apt, yum et rpm (un répertoire avec des paquets rpm). Ce qui montre qu'à l'époque de FC1, up2date devait rester pour longtemps dans Fedora. L'arrivée de Yum n'était pas prévu. Mais Yum a été proposé et il a été considéré qu'il était meilleur qu'up2date. Aujourd'hui up2date a été viré de Fedora et RHEL, pour RHEL5 qui sort début mars. Pour RHEL 5, Yum peut utiliser le protocole Red Hat Network.
> et qu'il fallait bien quelque chose de potable avant qu'ils réinventent la roue avec yum
Yum ne réinvente pas la roue.
- Yum est en python et Red Hat/Fedora utilise beaucoup Python. C'est le seul gestionnaire de paquet qui utilise Python avec Smart. L'installeur de Fedora, system-config-package, firstboot, etc utilise Python. Yum étant en Python, il s'integre à ces derniers sans problème.
- Yum utilise rpm-python au-lieu de réinventer la roue (rpm-python a été fait entre autre pour Anaconda)
- Yum utilise librpm pour résoudre les dépendance au-lieu de réinventer la roue. Tous les autres gestionnaires de paquet font la résolution de dépendance eux même et ce sont eux qui réinvente la roue.
- Pour vérifer l'installation/mise à jour/suppression de paquets (conflit de fichiers typiquement), Yum joue une transaction rpm "classique".
La dernier chose que fait yum, c'est de réinventer la roue.