Articles précédents : Logiciel
- [109] Sun Microsystems fait l'acquisition de MySQL
- [57] Le code source de SimCity libéré
- [139] Sortie de KDE 4.0
- [45] Sortie de digiKam 0.9.3
- [6] BOOop'solution : bulletin de paie en opensource
- [16] Sortie de Netbeans 6.0
- [20] CLFSWM - Un gestionnaire de fenêtres en Common Lisp.
- [3] Pymecavidéo, un remplaçant à regavi ou aviméca
- [26] Plee The Bear sort de sa tanière et ça va faire mal !
- [15] Bilboblog, une application libre en PHP de micro-blogging
Liens connexes
- rpm5.org (281 hits)
- l'annonce de la sortie de rpm5 (113 hits)
Dépêche modérée par
Dépêche éditée par
Il s'agit de la première version majeure de la version rpm5.org de RPM, le gestionnaire de paquets permettant de gérer l'installation de logiciels sur quelques distributions GNU/Linux. Pour rappel, rpm5 est le fork initié par Jeff Johnson après son départ de RedHat. Le RedHat Packages Manager est lui disponible en version 4.4.2.2 sur le site rpm.org.
Parmi les changements notoires :
- Nettoyage du code, y compris la partie autotools ;
- Choix du format de la rpmdb : Berkeley DB et/ou SQLite ;
- rpm5 a été porté sur de nouvelles architectures, y compris MacOS X ;
- Concernant les formats de compression, à gzip et bzip2 déjà pris en compte, a été ajouté le support du format lzma ;
- La liste des tags disponibles est désormais extensible : pour les distributions, le but est de pouvoir stocker des informations supplémentaire selon leurs besoins ;
- Il est désormais possible de marquer des macros en lecture-seule.
À savoir aussi que :
- Les fichiers de configuration 'rpmrc' (définition des architectures) ont été supprimés, au profit d'une configuration complète au travers de macros ;
- Le format rpm v3 n'est plus supporté.
![[en]](../../../images/en.png)
rpm5.org (281 hits)-
l'annonce de la sortie de rpm5 (113 hits)
> Lire la dépêche (81 commentaires, moyenne: 2,2).
R ?
Le R de RPM : c'est bien Redhat ?
Et si je comprends bien, rpm5 et "rpm" ne sont plus compatibles 100%.
et "rpm" est toujours le système de packages officiel de redhat ...
Par conséquent : encore une belle pagaille en perspective ;-)
deb rulez ;-)
-
[^]Re: R ?
-
[^]Re: R ?
Posté par Cheneson Cyril () le 17/01/2008 à 09:35. (lien). Évalué à 2.Le R de RPM : c'est bien Redhat?
Non , le R veut dire RPM. (C est la 1ere ligne de la news) :)
Tout comme WINE, le W veut dire WINE
Je crois bien qu' il y ait un nom a ca, mais je ne m'en souviens pas
@++-
[^]Re: R ?
-
[^]Re: R ?
Posté par FReEDoM (page perso, ) le 17/01/2008 à 09:50. (lien). Évalué à 2.Je crois bien qu' il y ait un nom a ca, mais je ne m'en souviens pas
c'est un acronyme récursif-
[^]Re: R ?
Posté par Nicolas Legrand () le 17/01/2008 à 13:34. (lien). Évalué à 10.Histoire de chipoter il s'agit plutôt d'un sigle récursif. Un sigle est une suite d'initiales au d'abréviation. L'acronyme est un sigle que l'on prononce en le lisant comme un mot.
Exemple :
GNU se prononce « gnou », c'est donc un sigle et un acronyme,
RPM se prononce « airpéhème », ce n'est donc qu'un sigle.
Je crois que c'est avec le GNU que Richard Stallman a initié beaucoup de blagues pas très drôles et surtout un confusion systématique pour le geek qui s'est mis à appeler acronyme tout sigle lui passant sous le nez.
J'ajouterai (parce que je suis gai comme un mormon) que je décourage fortement de faire des sigles juste parce qu'ils ont l'air sympa ou font un jeux de mot marrant en rapport avec ce qu'ils désignent. Non que ce ne soit pas bien : on en a juste trop.
Bisous ! (on fait jamais assez de bisous)
-
[^]Re: R ?
Posté par nayco (page perso, ) le 17/01/2008 à 15:32. (lien). Évalué à 1.C'est un acronyme récursif.
-
[^]Re: R ?
Posté par Calim' Héros (Jabber id, page perso, ) le 17/01/2008 à 15:56. (lien). Évalué à 0.C'est un acronyme récursif.
-
[^]Re: R ?
Posté par boklm (page perso, ) le 17/01/2008 à 18:07. (lien). Évalué à 0.C'est un acronyme récursif.
-
[^]Re: R ?
Posté par alouali (page perso, ) le 17/01/2008 à 19:25. (lien). Évalué à 0.C'est un acronyme récursif.
-
[+] [^]Re: R ?
-
[^]Re: R ?
Posté par Benoît Guédas (Jabber id, ) le 17/01/2008 à 19:44. (lien). Évalué à 2.Surtout que je ne vois pas vraiment où se trouve la récursion là-dedans, juste une pauvre bouclé itérative.
-
[^]Re: R ?
Posté par beagf (page perso, ) le 17/01/2008 à 21:34. (lien). Évalué à 8.ça dépend :
- tu descend toute la chaine de commentaire pour la lire et la mémoriser
- arriver en bas tu te rend compte à quel point c'est lourd...
- tu remonte la chaine en te rappellant des tous les commentaire, et en les moinsant au passage
sa peut se programmer de manière récursive (et bien plus éllegament qu'en itératif si tu n'aime utiliser explicitement un tableau ou autre pour stocker tes contextes)
Le problème ici c'est que je déconseille d'utiliser la récursivitée pour le faire sur linuxfr, les trolls pouvant parfois être extrèmement long il y a un risque d'exploser la pile...-
[^]Re: R ?
Posté par Mildred (Jabber id, page perso, ) le 24/01/2008 à 16:55. (lien). Évalué à 1.Enfin, si tu fais ta récursivité dans un bon langage en la programmant bien (c'est à dire en utilisant la récursion terminale) tu n'a aucun risque d'exploser ta pile. Donc je conseille le récursif.
-
-
-
-
-
-
-
-
-
-
[^]Re: R ?
Posté par Sytoka Modon (page perso, ) le 17/01/2008 à 09:39. (lien). Évalué à 3.Oui, à l'origine le R est celui de Redhat puis ils l'ont transformé en acornyme recursif...
Il est de même pour GCC...
Parfois, on garde même l'acronyme même si l'institution change de nom complètement, cf le CERN.-
[^]Re: R ?
Posté par GeneralZod () le 17/01/2008 à 15:32. (lien). Évalué à 7.Aux dernières nouvelles, GCC est toujours l'abbréviation de GNU Compiler Collection (à l'origine GNU C Compiler) et non pas un acronyme récursif GCC Compiler Collection.
-
Les distributions?
Quelle distribution utilise quoi? Je sais que chez Mandriva il était question de passer à la compression LZMA pour les RPM....
-
[^]Re: Les distributions?
Posté par baud123 (Jabber id, page perso, ) le 17/01/2008 à 10:09. (lien). Évalué à 3.au moins utiliser ce site (c'est la dernière utilité qu'il lui reste) :
http://fr2.rpmfind.net/linux/rpm2html/search.php?query=rpm&a(...)
Quasi tout le monde en 4.4 sauf de vieilles distrib' ;-)
sinon pour Mandriva
http://sophie.zarb.org/rpm/cooker,/rpm
-
[^]Re: Les distributions?
Posté par liberforce (Jabber id, page perso, ) le 17/01/2008 à 10:14. (lien). Évalué à 5.http://wiki.mandriva.com/en/2008.1_Detailed_Specifications#R(...)
Non évènement
Cette branche de RPM ne sera vraisemblablement utilisé pas personne (du moins pas par des distros importantes).
Pourquoi ? C'est la branche développée par Jeff Johnson et ce mec n'est visiblement pas fiable.
Comme RPM stagnait et que Jeff Johnson refusait de corriger des bugs gravissimes dans le code les distros majeures ont décidé de s'allier et de reprendre la main sur le développement de RPM.
Pour cela le site rpm.org a été créé ou le travail de maintenance a lieu....mais J. Johnson a lancé son site concurrent (rpm5.org) pour garder le contrôle du projet et essayer de tuer dans l'oeuf rpm.org.
Les distros n'ont pas mordu à l'hameçon et cette sortie de RPM 5.0.0 est donc un non évènement.
Il y a un commentaire ici ( http://lwn.net/Articles/263965/ ) dont je trouve qu'il résume bien la situation : "The last thing we need is to become dependent, again, upon a project headed up by a uncooperative developer. The XFree86->Xorg move has clearly been beneficial. Standardizing on the Jeff Johnson fork of RPM would be unwise, and a step backwards, in my opinion."
Une autre personne a écrit : "Based on my previous interaction with Jeff Johnson, I think I'll be giving this a miss. I'll stick with distributions using a package manager written by someone I trust to get it right. And I'm afraid that's just not Jeff...
Cette interaction désastreuse est visible ici : https://bugzilla.redhat.com/show_bug.cgi?id=119185
On voit que Jeff Johnson a joué à la tête de con (il n'y a pas d'autre mot) pour éviter d'avoir a corriger un bug conduisant à une corruption de la base RPM.
Un article de LWN résume bien les choses ( http://lwn.net/Articles/196523/ ) :
"The ensuing conversation - lasting for over two years - deserves to become a textbook example in how not to respond to bug reports. (...) Mr. Johnson repeatedly closed the bug, stating his refusal to fix it. Numerous other participants in the discussion made it clear that they disagreed with this "resolution" of the bug, but nothing, it seemed, could convince the RPM maintainer to put in a fix."
C'est ce genre de chose qui a forcé Red Hat, Fedora, OpenSuse a s'allier pour faire sortir RPM de sa stagnation : http://lwn.net/Articles/214255/
Conclusion : Comme avec XFree, je pense que cette branche RPM va tomber dans l'oubli.
-
[^]Re: Non évènement
Posté par GeneralZod () le 17/01/2008 à 10:45. (lien). Évalué à 3.Pour être honnête, Jeff Johnson a continué après son départ à maintenir RPM, mais quasiment aucune distribution n'a osé toucher à sa branche. jbj n'a pas été viré pour avoir refusé de corriger des bogues "gravissimes" mais pour son comportement cavalier avec les utilisateurs uniquement à propos du bug #11985 (et uniquement celui-ci). Ironie de l'histoire, il finira par corriger ce bug dans son fork (RPM 4.4.5).
Greg De Koenigsberg résume très bien la situation.
When we fired jbj, we didn't have the courage to draw a line in the sand and say "we're taking upstream ownership of RPM back." Why not? Because we thought it would be difficult politically? Because we didn't want the responsibility anymore? Because nobody in management actually cared enough to think about the ramifications? I don't know.
Fast forward a year plus, and here we are. We're in a position where we have, essentially, forked RPM -- and no one is willing to admit it. No one is willing to take ownership of what we've done.
Perhaps jbj "owns" RPM, in its current incarnation, by default, because no one else is willing to touch it. That's fine. He can have it. But that is not what *we* are using.
La vérité est qu'aujourd'hui RPM5 est plus avancé, il a fallu près d'un an à Paul Nasrat (mainteneur actuel) et à Panu Matilain pour prendre en main le code et le nettoyer, ça fait pas très longtemps que RPM a commencé à aller de l'avant.
Néanmoins, la période de "flottement" a prouvé que sans le soutien de RedHat , tout fork de RPM a peu de chances de survivre. Novell, MandrivaSoft (malgré un soutien affiché à RPM5) auraient pu récupérer la branche de jbj ou reprendre les choses en main, mais on attendu la réponse de RedHat.
De plus, la direction du fork ne plaisait pas spécialement à RedHat.
http://www.redhatmagazine.com/2007/02/08/the-story-of-rpm/
-
[^]Re: Non évènement
Posté par Olivier Thauvin (page perso, ) le 17/01/2008 à 10:50. (lien). Évalué à 5.Tes remarques indiquent que manifestement tu n'est pas au fait de beaucoup de choses.
C'est Jeff Johnson qui est parti de chez RedHat, la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer. D'ailleurs le RPM de rpm.org n'aura plus de changements majeur et gardera un grand nombre de lacunes. (AMHA)
Quand à la LSB, c'est un troll stérile. La LSB stipule qu'il faut utiliser le format RPM v3. Ce format était déjà obsolète au moment de l'écriture de la LSB ! Les débianneux apprécient aussi surement ce standard qui exclue de fait leur distribution (et ubuntu, et slackware, et gentoo, etc...)
Enfin parler d'une sortie de stagnation de la part de RedHat et OpenSuse c'est peu dire, il leur a fallu 2 ans pour se positionner et se remettre à toucher à leur RPM après le fork de Jeff Johnson. Et en plus ils ne sont pas parti de rpm 4.4.8 qui était le dernier dans le CVS encore commun, mais de rpm 4.4.2.
Pour le reste, le rpm générés par rpm5 sont compatibles avec rpm 4.x.-
[^]Re: Non évènement
Posté par patrick_g (page perso, ) le 17/01/2008 à 11:24. (lien). Évalué à 3.>>> Tes remarques indiquent que manifestement tu n'est pas au fait de beaucoup de choses.
Je suis toujours ravi d'apprendre des trucs.
>>> C'est Jeff Johnson qui est parti de chez RedHat, la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer.
Donc après son départ de Red Hat il est devenu le mainteneur upstream et il pouvait faire ce qu'il voulait...hors il a continué a refuser de corriger des problèmes (cf plus haut).
>>> Quand à la LSB, c'est un troll stérile.
Nulle part dans mon post je n'évoque la LSB. En parler est donc de ta part effectivement un troll stérile.
>>> il leur a fallu 2 ans pour se positionner et se remettre à toucher à leur RPM après le fork de Jeff Johnson
L'annonce de la reprise en main de RPM par les distros date du 14 décembre 2006 : http://lwn.net/Articles/214255/
Soit il y a un an et un mois (et pas deux ans).
Les premiers mois ont été consacrés (comme c'est normal lors d'une reprise) à s'approprier et nettoyer le code.
Ensuite, dès le 23 juillet (soit 7 mois après la reprise en main), la sortie de la version 4.4.2.1 : https://lists.dulug.duke.edu/pipermail/rpm-announce/2007-Jul(...)
Ensuite le 3 octobre la sortie de la 4.4.2.2 : https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-Octobe(...)
Tu peux voir que le changelog est assez conséquent. Ta phrase est donc tout simplement fausse.-
[^]Re: Non évènement
Posté par Olivier Thauvin (page perso, ) le 17/01/2008 à 11:45. (lien). Évalué à 4.Donc après son départ de Red Hat il est devenu le mainteneur upstream et il pouvait faire ce qu'il voulait...hors il a continué a refuser de corriger des problèmes (cf plus haut).
Et il l'a fait: rpm 4.4.4, 4.4.6, 4.4.8. Toutes ces versions ont existées avant que RedHat ne se bouge.
Nulle part dans mon post je n'évoque la LSB. En parler est donc de ta part effectivement un troll stérile.
L'article auquel tu fais référence en parle.
Soit il y a un an et un mois (et pas deux ans).
Je parle du délais entre l'annonce du départ de Jeff Johnson et donc d'un fork à venir au moment où RedHt à annoncé la mise en place du nouveau rpm.org.
Donc gosso modo du délai entre rpm 4.4.2 et 4.4.8.-
[+] [^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 14:32. (lien). Évalué à -2.> Et il l'a fait: rpm 4.4.4, 4.4.6, 4.4.8. Toutes ces versions ont existées avant que RedHat ne se bouge.
Red Hat a bougé. Fedora est resté à la version 4.4.2. Idem pour SuSE.
Ces trucs sont très compliqué à gérer. Rpm est largement utilisé, Red Hat n'allait pas fermer http://www.rpm.org/ et l'accès au CVS de Johnson du jour au lendemain. Il y a eu une transition. Mauvaise car il y avait conflit (ou suspicion)
Enfin, c'est gentil de critiquer Red Hat pour son manque de dynamisme, mais c'est le seul qui a repris les choses en main. Mandriva a rien foutu ni même donné un soutient (d'ailleurs Mandriva est passé à rpm 4.4.8 pour revenir à la branche Red Hat/Fedora).
Qu'au sein de Red Hat on critique la mollesse de Red Hat au début de cette affaire, je comprend très bien. Mais que les autres critiques alors qu'ils n'ont rien fait, je ne comprend pas.
En passant, Jeff Johnson est un excellent développeur qui a fait un excellent travail pour rpm.
-
-
-
[+] [^]Re: Non évènement
Posté par Xavier Bestel (Jabber id, page perso, ) le 17/01/2008 à 11:43. (lien). Évalué à -5.
C'est Jeff Johnson qui est parti de chez RedHat
Mwahahaa ! Le problème Jeff Johnson est connu depuis avant son licenciement.
Je ne comprends pas bien l'intérêt qu'il y a à le défendre. Groupie Mandriva ?-
[^]Re: Non évènement
Posté par Olivier Thauvin (page perso, ) le 17/01/2008 à 11:57. (lien). Évalué à 3.Moi je ne comprends pas pourquoi dans cette histoire les gens considère RedHat comme exemplaire.
Pour ma part, j'ai appris l'existence du "fork" de RedHat sur un des listes de rpm.
Ce mail nous expliquait que le cvs avait été migré sous mercurial et qu'ils cherchaient à regrouper les gens. En gros tout était fait.
Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.
Enfin pour ce qu'il s'est passé entre Jeff Johnson et RedHat, je ne pense pas que grand monde ait une vision claire.
Quand à Mandriva, je ne vois pas le rapport avec la choucroute.-
[^]Re: Non évènement
Posté par patrick_g (page perso, ) le 17/01/2008 à 12:04. (lien). Évalué à 3.>>> Enfin pour ce qu'il s'est passé entre Jeff Johnson et RedHat, je ne pense pas que grand monde ait une vision claire.
C'est clair qu'il nous manque peut-être des infos....mais la lecture des échanges sur le bugzilla montre bien la personnalité de JJ.-
[^]Re: Non évènement
Posté par imr () le 17/01/2008 à 15:04. (lien). Évalué à 2.Un point de vue depuis l'autre coté, ça aide toujours à équilibrer les choses:
http://trainofthoughts.org/blog/2008/01/06/rpm5-vs-rpm/-
[^]Re: Non évènement
Posté par Olivier Thauvin (page perso, ) le 17/01/2008 à 19:33. (lien). Évalué à 1.Ralf S. Engelschall fourni l'hébergement de rpm5.org.
Je ne sais pas trop de quel autre coté tu parles, mais donc il faut juste savoir ça.-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 19:47. (lien). Évalué à 1.> Je ne sais pas trop de quel autre coté tu parles
Il serait un peu bête de cherche un bon et mauvais côté.
Il y a eu désaccord entre Johnson et Red Hat.
Johnson n'a pas tenu de propos "orduriers" envers Red Hat et vice versa. Il n'y a pas eu de "sabotage", etc.
Red Hat a laissé le cvs de rpm.org à disposition de Johnson, ainsi que les mailings. Ceci afin qu'il continu son boulot avec ceux qui partage ses objectifs. Notons que même si Red Hat en avait le droit aux yeux de la lois, il ne pouvait pas décemment se le permettre.
Johnson n'a pas réclamé de "propriété" pour le nom RPM. Johnson ne prétent pas être LE rpm. En passant, rpm n'est pas une marque protégé, et on voit la confusion que ça crée. Pas de quoi en faire un formage dans ce cas.
-
[^]Re: Non évènement
Posté par imr () le 18/01/2008 à 02:45. (lien). Évalué à 3.L'autre coté, c'est lire le compte rendu de la même histoire mais d'après le point de vue de quelqu'un qui travaillait avec jbb pour pouvoir pondérer le total, pour répondre à patrick_g qui disait:
C'est clair qu'il nous manque peut-être des infos
On avait déjà 2 points de vue, celui des partisans de red hat qui ne voient aucune responsabilité de red hat dans cette affaire, tout est la faute à jbb, et celui des utilisateurs qui soit blamaient jbb, soit blamaient red hat.
Maintenant, on a le 3ème qui dit: jbb est un codeur génial, il ne pouvait pas faire évoluer le soft comme il voulait donc chez redhat et donc on lui a fait porter la responsabilité de ce genre d'affaires à tort, il est heureux d'avoir quitté red hat et depuis, il fait enfin évoluer son soft et du coup, ce fameux bug a pu être fixé.-
[^]Re: Non évènement
Posté par zero heure (Jabber id, page perso, ) le 18/01/2008 à 08:34. (lien). Évalué à 3.Il faut lire aussi ce qu'il (Engelshall) dit à propos du fameux bug: l'attitude de jbb ne lui semble pas anormale, particulière certes, mais compréhensible.
--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
-
-
-
-
-
[^]Re: Non évènement
Posté par nimnim () le 17/01/2008 à 14:13. (lien). Évalué à 5.> Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils
> allaient reprendre leur version, se sont déroulées sur les listes RedHat ou
> Fedora. Sûrement un signe d'ouverture.
Même pas toutes les discussions préliminaires se sont faites en interne Red Hat avec consultation discrète des autres distributions utilisant rpm.
Ce qui était parfaitement normal.
Il aurait été suicidaire pour Red Hat de faire une annonce publique sur le sujet avant :
A. d'avoir recruté des développeurs capables de reprendre la base de code
B. de s'être assuré que les autres distributions majeures utilisant rpm étaient prêtes à se joindre à l'aventure
C. d'avoir planifié la logistique pour remettre rpm.org en ordre de marche rapidement.
Un gestionnaire de paquets est le cœur d'une distribution Linux moderne. La moindre incertitude publique sur le devenir de rpm aurait été extrêmement dommageable pour toutes les distributions basées sur rpm. Et on pouvait compter sur jbj pour attiser la polémique (ce qu'il s'est empressé de faire avec rpm5.org)-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 14:48. (lien). Évalué à 1.> Même pas toutes les discussions préliminaires se sont faites en interne Red Hat
Tu parles de quoi ?
Oui Red Hat a eu des discussions en interne. Pour embaucher un développeur (mettre du "cash"), tu ne vas pas en discuter avec d'autres. Pour voir s'il est "rentable" de mettre un développeur ou deux sur rpm au-lieu de bidule, tu ne vas pas en dicuter avec les autres.
> avec consultation discrète des autres distributions utilisant rpm.
Il y a toujours des contacts "privés". Mais la consultation a été annoncée très tôt et de façon public. Et en gros on peut affirmer qu'elle a été quasiment ignorée (il n'y a que SuSE qui a donné son soutient à Red Hat pour relancer rpm.org).
Je pense que les messages "privés" ont dû être hypra limité si jamais ils ont existé.
-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 14:55. (lien). Évalué à 3.> Un gestionnaire de paquets est le cœur d'une distribution Linux moderne.
Non, non et non.
Si je passe d'Ubuntu à Mandriva je change de coeur ?
Je ne crois pas. Il y a des distributions rpm qui utilisent synaptic par défaut et l'ancien utilisateur de deb ne se rend même pas compte qu'il est passé à rpm avant d'avoir gratté un peu le verni.
C'est un élément très très important pour certains utilisateurs (développeurs, etc).
Mais ce n'est pas plus le coeur que Linux (le noyau), la libc, X11, un système de fichier, etc...-
[^]Re: Non évènement
Posté par nimnim () le 17/01/2008 à 21:07. (lien). Évalué à 5.Oui, oui et oui.
Tu peux changer la version majeure du noyau, de la libc, de X11, etc et toutes les distributions le font régulièrement.
Aucune distribution sérieuse ne va s'amuser à changer de gestionnaire de paquet comme ça. C'est trop impactant. Une distribution se définit par sa ligne éditoriale et le gestionnaire de paquets est l'outil privilégié pour l'appliquer. Même quand plusieurs distributions utilisent le même gestionnaire de paquets le jeu fonctionnel utilisé diffère généralement. Et de nombreuses distributions ont été fondées autour d'un choix de gestionnaire de paquets qu'elles doivent ensuite gérer pendant des années.
Sans le gestionnaire de paquet et ses fichiers connexes, tu n'as plus de distribution mais la masse de code source qui lui sert de matière première.-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 21:58. (lien). Évalué à 1.> Aucune distribution sérieuse ne va s'amuser à changer de gestionnaire de paquet comme ça.
Ou changer de compilateur, etc...
> C'est trop impactant.
Comme le changement du compilateur. Le compilateur serait le "coeur" de l'OS ?
On ne devrait plus dire GNU/Linux mais GCC/Linux ?
> Une distribution se définit par sa ligne éditoriale et le gestionnaire de paquets est l'outil privilégié pour l'appliquer.
Ça dépend des distributions.
Donc selon toi Xandros == Debian ?
CentOS == Mandriva ?
> Sans le gestionnaire de paquet et ses fichiers connexes, tu n'as plus de distribution mais la masse de code source qui lui sert de matière première.
Pareil pour gcc.-
[^]Re: Non évènement
Posté par nimnim () le 18/01/2008 à 20:16. (lien). Évalué à 4.Sans vouloir te vexer, si un rpm Mandriva ne s'installe pas sous Fedora c'est que la réalité est un peu plus complexe que ta vision des choses.
Avec ton niveau d'argumentaire vache == cheval (après tout c'est des mamifères à quatre pattes qui mangent de l'herbe).
C'est bien de prendre de la hauteur mais à trop forcer on finit par ne plus rien distinguer.-
[^]Re: Non évènement
Posté par IsNotGood () le 19/01/2008 à 03:01. (lien). Évalué à 2.> Sans vouloir te vexer, si un rpm Mandriva ne s'installe pas sous Fedora c'est que la réalité est un peu plus complexe que ta vision des choses.
Je ne vois où tu veux en venir a part conclure que le gestionnaire de paquet n'es tpas le coeur d'une distribution.
> Avec ton niveau d'argumentaire vache == cheval
Tu changes bien le coeur des OS seulement avec un gestionnaire de paquet.
Une vache à quatre pattes, comme un cheval.
Ça bouffe comme un cheval, ça a un regard attendrissant, et désolé, ça peut aussi se manger. Bref, plein de point en commun. Et au niveau ADN on doit avoir dans les 95 % d'ADN commun.
Mais tu veux faire de l'oreille de la vache son coeur (dans le sens "centre", "essence" et pas organe). Partant de la et constatant que l'oreille de la vache est différente de l'oreille du cheval, tu conclus qu'une vache et un cheval ça n'a rien à voir. Les anes et les chevaux n'ont pas les même oreilles.
Je te laisse à ton fétichime du gestionnaire de paquet.
-
-
-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 22:26. (lien). Évalué à 1.Et joubliais un "petit truc".
Tu peux installer des rpm sur Debian/Slack/etc. Et les programmes marcheront.
Pour l'utilisateur que ça soit "apt install" ou "yum install" ne change pratiquement rien. On trouve des programmes qui interfacent deb et rpm. Si PackageKit devient populaire, sûr que beaucoup d'utilisateurs ne sauront plus quel gestionnaire ils utilisent.
Les gestionnaires de paquet sont une "commodité". Certes importante pour des développeurs/admins, mais c'est tout. Ce n'est pas le coeur de l'OS. Loins loins de la.
Que dirais-tu si Windows passe à Deb ? Que Windows a changé de coeur ? Que Windows == Debian ?
Quand quelqu'un veut changer d'OS, le ne dit pas "je cherche un OS avec un coeur rpm". Il va dire qu'il veut un OS pour le desktop, pour faire un serveur, qu'il veut du "blengind edge", qu'il veut KDE ou Gnome, du sans proprio, etc.
Beaucoup de gens veulent conserver une barrière (artificielle) entre les distributions selon le gestionnaire de paquet. D'autant plus quand c'est pour surfer sur le "rpm puxor" et "donc" que l'autre distribution est nulle.
Tout ça c'est de la merde.
Le cas où ça commence à devenir vaguement pertinant, c'est pour les distributions orientés sources vs distribution "normal".-
[^]Re: Non évènement
Posté par Mildred (Jabber id, page perso, ) le 24/01/2008 à 17:10. (lien). Évalué à 1.Quand quelqu'un veut changer d'OS, le ne dit pas "je cherche un OS avec un coeur rpm". Il va dire qu'il veut un OS pour le desktop, pour faire un serveur, qu'il veut du "blengind edge", qu'il veut KDE ou Gnome, du sans proprio, etc.
Mon choix pour ArchLinux s'est fait par rapport entre autre à Fedora car je cherchais un OS avec un système de paquets facile a utiliser (comprendre, facile a créer et installer des paquets).
Sinon, Fedora, je trouvais bien. Tout ou presque fonctionne par défaut, pas besoin de configurer à la main ... du bonheur quoi. Sauf quand il fallait installer un logiciel tiers.
-
-
-
-
-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 14:40. (lien). Évalué à 1.> Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.
En passant, toutes les mailing Fedora sont ouvertes.
Avant le départ de Johnson le problème a été posé.
Red Hat n'a peut-être pas été exemplaire, mais que dire des autres ?
C'est marrant cette façon de critiquer Red Hat alors qu'en même temps on attend tout de Red Hat. Les gens n'attendent rien de SuSE (pourtant ils utilisent rpm), rien de Mandriva (pourtant ils utilisent rpm), etc...
> Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.
Et alors ?
Red Hat devait s'inviter sur les mailling Debian pour discuter de rpm ? Pour discuter s'il fallait débloquer des fonds pour embaucher ? Pour évaluer en quoi rpm est critique pour le business de Red Hat ?
C'est ridicule.
-
[+] [^]Re: Non évènement
Posté par Matthieu Lagouge (Jabber id, page perso, ) le 17/01/2008 à 16:02. (lien). Évalué à -1.Quand à Mandriva, je ne vois pas le rapport avec la choucroute.
Ben si! Mandriva va utiliser rpm5 pour débuter l'unification des distros linux basées sur rpm en partenariat avec Turbolinux!!
Poussez pas toute façon je cours vite!! ----> [ ]
-
-
-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 14:21. (lien). Évalué à 2.> la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer.
Que non. Il proposait des évolutions que ne voulais pas son employer. Notons que SuSE a très tôt indiqué que la direction de Johnson ne leur plaisait pas et qu'il resterait, comme Fedora, à la version 4.4.2. Mandriva a fait comme d'hab : ignoré Red Hat/Fedora "officiellement".
Chez Red Hat, il suffit de regarder Fedora, il y a une grand latitude pour l'initiative des développeurs (du moment que les questions prioritaires sont réglées : sécurité, support, etc).
Il n'a pas écouté son employeur, il a été viré. Ou on lui a indiqué avec insistance la direction de la porte. Si j'ai bonne mémoire, lors des 8 derniers mois de Jeff Johnson chez Red Hat, il y avait un fork pour Fedora (d'où Fedora qui est resté à la version 4.4.2 et une grosse pile de patch).
> C'est Jeff Johnson qui est parti de chez RedHat
Il n'est pas parti, on l'a viré. Les choses n'ont peut-être pas été aussi "violente". M'enfin, tu le dis, tout ce qui a fait après 4.4.2 a été pris avec des pincettes.
> D'ailleurs le RPM de rpm.org n'aura plus de changements majeur
Que tu dis.
Et quel changement majeur tu veux ? Que rpm passe à deb ?
Soit plus spécifique.
> et gardera un grand nombre de lacunes. (AMHA)
Quelles lacunes ?
Qu'un truc ne soit pas parfait, ça toujours comme ça.
Compare avec deb (et non apt), et rpm est sans problème aussi bon (voir aussi rpmbuild).
> Les débianneux apprécient aussi surement ce standard qui exclue de fait leur distribution (et ubuntu, et slackware, et gentoo, etc...)
Pourquoi ? C'est un format. Prend le format deb, et t'as le même problème.
Il fallait un format. Il fallait faire un choix, "trancher".
Lsb est surtout pour les ISV (Independent software vendor). Et dans ce domaine l'histoire montre que choisir rpm au-lieu de deb est "normal". Je ne dirais pas que c'était incontournable. M'enfin, deb apporte quoi de plus ? À part le tag "suggestion" ?
> Et en plus ils ne sont pas parti de rpm 4.4.8 qui était le dernier dans le CVS encore commun, mais de rpm 4.4.2.
Beaucoup d'éléments des version post 4.4.2 sont dans la 4.4.2.
L'un des problèmes de rpm, est qu'il roxe. Oui, oui. Oublions tout le FUD, rpm roxe. Il fait son taff et on l'oublie. Trouver des développeurs pour rpm alors que rpm fait l'affaire est "compliqué".-
[^]Re: Non évènement
Posté par pomperoi (page perso, ) le 17/01/2008 à 15:43. (lien). Évalué à 3.L'un des problèmes de rpm, est qu'il roxe. Oui, oui. Oublions tout le FUD, rpm roxe. Il fait son taff et on l'oublie. Trouver des développeurs pour rpm alors que rpm fait l'affaire est "compliqué".
C'est comme perl quoi.
-
[^]Re: Non évènement
Posté par briaeros007 () le 17/01/2008 à 15:45. (lien). Évalué à 3.perso je sais pas ce que deb apporte par rapport à rpm, mais une chose est sur , si apt c'est top cool par rapport à yum.
sous fedora ou sous centos ou mandriva, les updates, ajouter ou retirer un paquet , etc... c'est LENT!
alors, est ce que RPM5 (pas le format, l'ensemble des outils;)) est aussi rapide qu'aptitude ?
(c'est une vrai question)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 16:44. (lien). Évalué à 0.> les updates, ajouter ou retirer un paquet , etc... c'est LENT!
C'est lent comment ?
J'ai fait un test avec un machine virtuelle (installe mini-mini, kvm en full-virtualisation, périphérique loopback).
[root@rslnvirt ~]# time yum install openoffice.org-draw openoffice.org-math openoffice.org-langpack-fr openoffice.org-calc openoffice.org-impress openoffice.org-graphicfilter openoffice.org-writer
[...]
Transaction Summary
=============================================================================
Install 137 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 184 M
[...]
real 1m58.744s
user 0m28.640s
sys 0m15.213s
Moins de 2 minute pour 184 Mo compacté.
[root@rslnvirt ~]# time yum remove glib2
[...]
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 90 Package(s)
[...]
real 0m26.932s
user 0m8.586s
sys 0m4.740s
Il y a peut-être plus rapide, mais plus rapide je m'en fous.-
[^]Re: Non évènement
Posté par Etienne () le 17/01/2008 à 17:06. (lien). Évalué à 2.Je pense qu'il faisait plutot allusion à ça :
# time yum -C search mutt
[...]
real 0m14.672s
user 0m10.161s
sys 0m2.584s
#
14 secondes, je trouve que c'est long pour une recherche locale. Surtout que sur une debian qui est moins puissante que la machine où la redhat (5.1) est installée :
$ time apt-cache search mutt
[...]
real 0m2.404s
user 0m1.256s
sys 0m0.236s
$
Et la debian me sorte nettement plus de packages (35 différents contre 2 fois le même packages pour la redhat).-
[^]Re: Non évènement
Posté par GeneralZod () le 17/01/2008 à 17:25. (lien). Évalué à 1.Sur la Fedora 8 du boulot:
$ time yum search mutt
[...]
real 0m1.822s
user 0m1.546s
sys 0m0.216s
$ yum --version
3.2.8
-
[^]Re: Non évènement
-
-
[^]Re: Non évènement
Posté par lezardbreton (Jabber id, page perso, ) le 17/01/2008 à 17:26. (lien). Évalué à 5.Perso, pour moi simple utilisateur, c'est la recherche qui me bloque le plus. Yum search est affreux par défaut, très lent, et indiquant des paquets plusieurs fois s'ils sont dans plusieurs dépôts. En plus, je n'ai pas compris comment faire pour n'afficher que le nom des paquets et non pas toute la description.
Je ne suis pas qualifié pour dire si la lenteur est dû à rpm ou yum. Cependant, il est clair qu'un urpmq -y est largement plus rapide et plus efficace, même si pas aussi rapide que apt-cache.-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 18:38. (lien). Évalué à 4.> En plus, je n'ai pas compris comment faire pour n'afficher que le nom des paquets et non pas toute la description.
Fait "yum install yum-utils".
il y a repoquery dedans :
[test@one ~]$ repoquery --all | wc -l
11531
[test@one ~]$ repoquery --all | grep mutt
mutt-5:1.5.17-2.fc8.x86_64
[test@one ~]$ time repoquery --all --queryformat="%{NAME} %{ARCH} %{LICENSE}\n" | grep -i mutt
mutt x86_64 GPLv2+ and Public Domain
real 0m3.999s
user 0m3.766s
sys 0m0.247s
[test@one ~]$ repoquery --querytags | wc
28
4 secondes pour 11500 paquets, ça va.
On peut faire des choses plus exotiques :
repoquery --provides java-1.7.0-icedtea | xargs repoquery --whatrequires --queryformat="%{NAME}\n" | sort | uniq
avalon-logkit
axis
azureus
bolzplatz2006
castor
checkstyle
classpathx-mail
dtdparser
freecol
graphviz-java
...
Pour confort tu peux te faire des alias.-
[^]Re: Non évènement
Posté par lezardbreton (Jabber id, page perso, ) le 17/01/2008 à 19:55. (lien). Évalué à 2.Ha, je connaissais pas, merci pour le tuyau.
-
-
-
[^]Re: Non évènement
Posté par vladislav askiparek () le 19/01/2008 à 20:48. (lien). Évalué à 0.Putain, la vache! 14sec!!
C'est vrai quoi, si à l'heure actuelle, on est pas capable de descendre sous les dix secondes pour chercher un soft alors qu'on court cent mètres en moins de dix secondes, où va-t-on!
...
Vous êtes ridicules de parler de 'long' en parlant de 14 sec. Ça dépend de tellement de choses:
installation (desktop, server,...)
occupation du disque
cpu
mem
....
Ridicule
J'ai pas trouvé d'autre synonyme, et j'ai pas 14 sec à perdre à ce genre de foutaise.
Faudrait pas oublier que Linux est multitâches, c'était son principal atout à l'époque, dans les années '90. Alors pendant que rpm cherche ton soft, regarde un divx, ça t'aidera à prendre patience.
La patience est la reine des vertus.
-
-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 17:06. (lien). Évalué à 1.> Moins de 2 minute pour 184 Mo compacté.
df avant/après :
[root@rslnvirt ~]# df . ; df -i .
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/sda1 3960316 823212 2932680 22% /
Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
/dev/sda1 1022976 26725 996251 3% /
[root@rslnvirt ~]# df . ; df -i .
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/sda1 3960316 1347248 2408644 36% /
Sys. de fich. Inodes IUtil. ILib. %IUti. Monté sur
/dev/sda1 1022976 47104 975872 5% /
Plus de 500 Mo installé, soit plus de 4,3 Mo/s.
Plus de 20 000 fichiers/répertoires, soit 170 fichiers/s.
En passant, les paquets sont downloadés depuis un réseau local et non depuis internet.
-
[^]Re: Non évènement
Posté par briaeros007 () le 18/01/2008 à 11:47. (lien). Évalué à 2.c'est lent du style plusieurs minutes.
Visiblement c'est quand il construisait un index.
J'avoue que j'ai pas beaucoup regardé.
Une grosse update c'est(était) lent aussi. Alors peut être que la façon de recupérer les fichiers d'index ne conviennent pas autant que pour debian, mais bon je trouvais ça vraiment lent (purement subjectif donc) (maintenant la machine est sous debian XD).
Pour finir sur les "mauvais point avec le gestionnaire de paquetage" :
lors de l'installation ... fc8 ne sait PAS faire de netinstall.
J'ai tout essayé, incapable de me faire une netinstall sur un serveur http public....
Et il faut aller chercher le miroir que l'on veut, et noter le path sur un papier pour l 'installer.
Et sait pas installer une fc8 avec juste le premier cd de tête en plus /o\
J'ai installé une debian, il me demande quel mirroir je veux dans une liste, et fait tout comme un grand.
Il me demande aussi si je veux mettre à jour quand je fais une install "standard", et me re-propose la liste des miroirs.
Bref, niveau netinstall debian 1, fedora 0 pour moi.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Non évènement
Posté par IsNotGood () le 19/01/2008 à 03:13. (lien). Évalué à 2.> fc8 ne sait PAS faire de netinstall.
C'est f8 en passant.
Et f8 c'est faire une installation via réseau (je l'ai fait).
Fedora fait ça depuis le FC1 !
Mieux, tu peux aussi faire une installation réseau via vnc.
Il y en a qui installe Fedora, graphiquement, sur dédibox.
Tu peux le faire avec Debian ?
> Et sait pas installer une fc8 avec juste le premier cd de tête en plus /o\
Admettons.
Tu peux installer via bootp (noyau et initrd récupéré sur le réseau).
Je veux bien admettre que ça manque de polish.
Mais ça marche puis des années ! Depuis RH 6.2 au moins (j'ai fait des netinstall avec RH 6.2).
> Il me demande aussi si je veux mettre à jour quand je fais une install "standard"
Tu peux faire l'installation et la mise à jour en même temps sous Fedora. Dans ce cas Fedora ne va pas installer toto v1 (de la release) puis mettre à jour vers toto v2 (des mises à jours). Il installe directement toto v2.
Je peux d'affirmer de façon définitive que ça le fait car je le fais et les dépôts utilisés sont sur une de mes bécanes (donc j'ai le log apache pour confirmer).
Il suffit à l'installation d'ajout un dépôt avec les mises à jours.
Alors pas d'accord pour dire que Fedora ne fait pas de netinstall. Fedora (et Red Hat) le fait depuis des lustres. Par contre, je suis tout à fait d'accord pour dire que ça manque de polish et qu'il faut lire un peu de doc (donc ce n'est pas accessible pour un newbi qui ne veut pas se prendre la tête).-
[^]Re: Non évènement
Posté par briaeros007 () le 20/01/2008 à 19:33. (lien). Évalué à 0.Et f8 c'est faire une installation via réseau (je l'ai fait).
Ben tu es un surhomme alors.
Parce que j'ai essayais toute une journée, changé les miroirs itou ... a jamais voulu marcher.
Le mieux que j'ai pu avoir c'est commencer l'install, mais lors de la liste des packages il trouvait jamais rien /o\ (hors si il commençait l'install, il allait chercher l'installateur sur le réseau, vu que j'ai essayé avec une image netinstall puis, voyant que ça ne marchait pas, un cd)
... miroirs que je devais noter sur un bout de papier , le path aussi . Qu'est ce qu'on se marre \o/
Fedora fait ça depuis le FC1 !
Assez mal il faut croire..
Ps : tous les miroirs que je testent sont sur internet, pas sur un intranet.
Tu peux le faire avec Debian ?
Aucune idée, tant que faire une netinstall simple avec FC8 n'est pas dispo, savoir qu'on peut faire le café avec fc8 ne m'intéresse guère.
Je peux d'affirmer de façon définitive que ça le fait car je le fais et les dépôts utilisés sont sur une de mes bécanes (donc j'ai le log apache pour confirmer).
Il suffit à l'installation d'ajout un dépôt avec les mises à jours.
"J'aime bien le "il suffit".
Regarde comment fait debian, tu verras que c'est BEAUCOUP plus intuitif.
Déja : tu n'as RIEN a noter! avec les risques d'erreur que ca comporte (le path je le prend en absolu ? je dois taper l'arch et la version ou pas ? ...)
Deuxio : pour la maj il te le propose, ce n'est pas a toi de penser de rajouter un dépôt etc...
Alors ca peut te paraitre con, mais désolé, ce sont des choses qui sont vraiment agréables quand tu teste une nouvelle distrib : tu ne dois pas penser à tout, et si tu la teste, c'est que par definition, tu ne connais pas tous les "trucs"...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Non évènement
Posté par Michel Galle () le 21/01/2008 à 13:44. (lien). Évalué à 1.dans le cadre de mon travail nous faisons de l'installation réseau avec fedora
actuellement en fedora core 6.
fedora hérite de redhat , tout naturellement.
on indique un "kickstart" (on le stock sur un serveur http ou nfs) via dhcp à l'installateur redhat/fedora
l'installateur peut être donné à l'ordinateur via un cdrom, bootp ou autre
le kickstart va indiquer à l'installateur où chercher ses paquets et quoi mettre , les paquets seront simplement disponible sur un mirroir de cd redhat/fedora en http (ou autre, nfs, voir smb je pense maintenant est possible)
bref, y a de nombreuses possibilités , le plus simple étant un cdrom avec un boot personnalisé (isolinux.cfg) pour aller chercher un kickstart sur un serveur web avec un les rpm sur un serveur web.
--
notons que le kickstart cherché peut dépendre du nom de la machine (donné par dhcp), peut être généré par php avec des paramètres etc. on peut imaginer beaucoup de possibilité.
-
notons aussi que toute install de redhat/fedora génère un fichier kickstart (dans /root) résumant la configuration et qu'il faut juste avoir la copie d'un cd d'install sur un serveur web pour disposer d'un netinstall fonctionnel
on prend le cdrom d'install habituel, on boot la machine, on indique d'installer par réseau, on lui donne l'adresse http et zou. c'est très facile ce niveau là, suffit d'avoir copier son cd/dvd dans un site web accessible.
si on ne donne pas d'indication où trouver un fichier kickstart, il faudra configurer à la main l'installation, les paquets seront pris depuis l'adresse indiquée.
-
dhcp permet d'indiquer où trouver le fichier kickstart pour automatiser l'installation.-
[^]Re: Non évènement
Posté par imalip (page perso, ) le 21/01/2008 à 14:14. (lien). Évalué à 3.C'est cool, kickstart, bootp/tftp, PXE, tout ca. Ca fait quand meme un poil lourd pour installer une seule machine...
Maintenant je pense que ce a quoi il fait référence, c'est les versions businesscard et netinst des CD d'install Debian. Le premier (32Mo) a juste l'installeur, le 2eme (159Mo) les paquets du systeme de base en plus ; et dans les 2 cas, ca propose une liste de mirroirs officiels depuis lesquels l'installeur va joyeusement télécharger les packages en fonction de ce qui a été demandé.--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: Non évènement
Posté par briaeros007 () le 21/01/2008 à 22:02. (lien). Évalué à 1.toutafé ;)
Et la version "cdrom" , te propose aussi d'aller vérifié les maj lors de l'install (toujours avec une liste de miroirs officiels).--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: Non évènement
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 22/01/2008 à 23:09. (lien). Évalué à 1.C'est cool, kickstart, bootp/tftp, PXE, tout ca. Ca fait quand meme un poil lourd pour installer une seule machine...
Tout comme avec Debian, tu n'es pas obligé de sortir l'artillerie lourde : il suffit de disposer du fichier « ks.cfg » sur un média accessible lors de la phase d'initialisation (comme une disquette).
Et, cela dit, pour pouvoir ré-installer une machine à l'identique, il n'y a guère d'autres méthodes que d'utiliser des outils automatiques. Ce n'est pas plus lourd qu'une procédure rédigée avec les différentes étapes à faire. C'est même plus sûr qu'un être humain, qui peut être tenté de passer outre les recommandations.
-
-
[^]Re: Non évènement
Posté par briaeros007 () le 21/01/2008 à 22:00. (lien). Évalué à 1.le kickstart va indiquer à l'installateur où chercher ses paquets et quoi mettre , les paquets seront simplement disponible sur un mirroir de cd redhat/fedora en http (ou autre, nfs, voir smb je pense maintenant est possible)
C'est bien beau, mais quand tu a fait tout ça, et qu'il se borne a te dire qu'il trouve aucun paquet... ben tu est très content de savoir qu'il peut le faire ... mais ca serait bien mieux qu'il le fasse!
Et encore une fois, c'est pas un problème d'url vu qu'il a trouver l'installateur sur la machine distante.
Je ne dis pas que je me suis peut etre trompé qq part... mais ca fait plus de 5 ans que j'installe du linux divers et varié, et j'ai essayé de l'installer pendant toute une journée. Donc je me dis, a tort peut être, que malgré ma maladresse légendaire y'a quand meme une couille dans le potage.
Et le réseau marche très bien vu qu'avec debian ce fut fait en moins de 45 minutes.
Peut etre les différents miroirs qui avait, tous ceux que j'ai testé, aucun index qui était correct ?--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
[^]Re: Non évènement
Posté par _seb_ () le 17/01/2008 à 17:00. (lien). Évalué à 4.Un paquetage RPM (package) est un fichier avec un format spécifique (format RPM).
Pour gérer ce format de fichier, il y a une bibliothèque (library) qui permet de manipuler les fichiers d'installation (et autres) inclus dans le paquetage RPM.
Cette bibliothèque permet également d'installer ces fichiers d'installation (entre autres) et de gérer une base de logiciels installé sur le système (plus exactement les paquetages installés).
Des outils sont également fournis pour donner à l'utilisateur la possibilité..et bien d'installer, de supprimer, de rechercher, etc des paquetages RPM sur le système uniquement.
Tout cela, c'est RPM.
Yum n'est qu'un enrobeur pour RPM. Il télécharge le paquetage RPM sélectionné ainsi que ses dépendances (paquetages RPM également), puis les installe et cela en s'appuyant sur les outils et bibliothèque RPM. Yum ne gère pas la base des paquetages RPM installés sur le système. Cette tâche est gérer par RPM en tant que tel.
Idem pour Aptitude. Aptitude fait confiance à RPM pour faire les installations correctement sur le système.
alors, est ce que RPM5 (pas le format, l'ensemble des outils;)) est aussi rapide qu'aptitude ?
(c'est une vrai question)
Non, ce n'est pas une vraie question puisque Aptitude a besoin de RPM (quelque soit sa version) pour fonctionner. RPM5 n'a pas pour vacation de remplacer Aptitude ou Yum.
Une vraie question est pourquoi RedHat (et autres distribution) n'ont pas poussé plus en avant le développement de RPM afin de :
- corriger les bugs
- faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.
- faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.
Cette dernière évolution permettrait de rendre Yum, Aptitude et autres beaucoup plus rapide (taille des fichiers télécharger réduite). Quelques projets ont tenté de s'y atteler mais la tâche n'est pas simple.
RPM ayant stagné pendant pas mal de temps, il était de plus en plus difficile de faire évoluer RPM. De nombreux logiciels ont été distribués sous forme RPM, des chaînes de création automatique de paquetage RPM relativement complexes ont été mise en place pour certains logiciels (le noyau de Redhat par exemple), sans oublier que RPM remplit assez correctement sa tâche...tout cela n'a fait que ralentir les évolutions sur RPM.-
[^]Re: Non évènement
Posté par IsNotGood () le 17/01/2008 à 17:17. (lien). Évalué à 1.> - faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre
Comprend pas.
Rpm est largement utilisé par les distributions. Si tu dis ça en t'appuyant sur le constat que seul les distributions utilisant rpm utilise rpm, ben seul les distributions utilisant deb utilise deb.
Je ne crois que deb soit plus portable (rpm est aussi utilisé sur Unix et pas seulement Linux).
> et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.
C'est plus simple avec deb ?
Faire un paquet rpm n'est pas compliqué. Mais c'est comme tout, il faut apprendre.
> - faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.
Su le fait depuis longtemps.
> mais seulement les différences d'une version à une autre.
C'est fait depuis une version de "référence". S'il y a toto-1, puis toto-2, puis toto-3, lorsque tu va downloadé toto-3, ça va être le diff entre toto-1 et toto-3. Sinon ça fait trop de boulot coté serveur, trop de version à gérer, etc.
> Cette dernière évolution permettrait de rendre Yum, Aptitude et autres beaucoup plus rapide
Pas forcément, il faut reconstruire le paquet. Il y a un gain lorsqu'il faut downloader, mais après c'est plus lent. Si t'as une excellent connexion internet, ça ne sera peut-être pas toujours un gain.-
[^]Re: Non évènement
Posté par Etienne () le 17/01/2008 à 17:24. (lien). Évalué à 1.Pas forcément, il faut reconstruire le paquet. Il y a un gain lorsqu'il faut downloader, mais après c'est plus lent. Si t'as une excellent connexion internet, ça ne sera peut-être pas toujours un gain.
Ca peut par contre baisser la charge et la bande passante côté serveur, certe ça prend plus de place mais l'espace disque est moins cher que la bande passante (et tu le paye qu'une fois).
Etienne-
[^]Re: Non évènement
-
-
-
[^]Re: Non évènement
Posté par briaeros007 () le 18/01/2008 à 11:48. (lien). Évalué à 2.Non, ce n'est pas une vraie question puisque Aptitude a besoin de RPM (quelque soit sa version) pour fonctionner. RPM5 n'a pas pour vacation de remplacer Aptitude ou Yum.
Note : bien lire la question avant d'affirmer que je ne sais pas ce que je voulais dire merci.
s/RPM/deb/
hint :
(pas le format, l'ensemble des outils;))--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: Non évènement
Posté par Michel Galle () le 21/01/2008 à 13:53. (lien). Évalué à 3.>- corriger les bugs
quels bugs ?
>- faire évoluer le format RPM pour qu'il soit plus portable d'une distribution à une autre et qu'il soit plus simple pour les développeurs d'empaqueter leurs logiciels dans un fichier RPM.
rpm est portable. ce sont les disttributions qui choisissent de ne pas utiliser les mêmes version de logiciels , de changer les chemins d'installation etc.
mais rpm est utilisé même dans des unix. c'est du "portable". un paquet rpm qui installe des fichiers dans /opt/toto marcherait sur fedora, mandriva, suse etc. même debian via alien.
il marcherait aussi sur les unix avec rpm. il copierait en tout cas les fichiers demandé là où on lui dit.
bref, le format rpm est portable. aux gens de normaliser les distributions linux pour que je puisse installer le dernier firefox sur toutes mes distribs sans attendre 250 forks.
@- faire évoluer le système d'installation afin de ne pas à avoir à retélécharger tout le fichier RPM, mais seulement les différences d'une version à une autre.
c'est une idée en cours oui.
-
-
-
-
bsdiff...
C'est un peu hors-sujet, mais qqun sait-il pourquoi les distributions ne proposent jamais de rpm "différentiels" ? D'un binaire version n à sa version n+1, je suis sûr que la différence (via bsdiff, xdelta ou sdelta) doit être de taille minime, et pour upgrader ma Mandriva je préfèrerais de loin ne télécharger que la différence plutôt que les packages entiers (surtout pour des gros trucs comme KDE ou OpenOffice !)...
Peut-être qu'il y a une bonne raison de ne pas le faire ("patcher" via bsdiff a peut-être des inconvénients), mais pour l'instant je ne vois pas !
-
[^]Re: bsdiff...
Posté par IsNotGood () le 17/01/2008 à 16:47. (lien). Évalué à 1.bsdiff, je ne sais pas ce que c'est.
Suse l'a fait (ou le fait toujours).
Fedora va le faire :
http://fedoraproject.org/wiki/Releases/FeaturePresto
-
[^]Re: bsdiff...
Posté par _seb_ () le 17/01/2008 à 17:13. (lien). Évalué à 1.C'est aussi l'une des améliorations de RPM que j'attends avec impatience depuis longtemps.
La solution retenu par Fedora est de recréer la paquetage installé depuis la base RPM,d'y appliquer le patch téléchargé pour en faire un nouveau paquetage RPM qu'on installalera de façon traditionnelle.
DeltaRPM fait à peu près la même chose.
Au final, on a tout de même un nouveau paquetage RPM qui installera des fichiers qui n'auront pas été modifiés.-
[^]Re: bsdiff...
Posté par GeneralZod () le 17/01/2008 à 17:26. (lien). Évalué à 2.Presto repose sur deltarpm au passage ...
D'ailleurs j'utilise Presto depuis Fedora 7 et ça marche super bien.-
[^]Re: bsdiff...
Posté par IsNotGood () le 17/01/2008 à 18:41. (lien). Évalué à 1.Où tu as trouvé un dépôt qui propose du deltarpm ?
-
[^]Re: bsdiff...
Posté par benja () le 18/01/2008 à 01:20. (lien). Évalué à 1.À un click ("Presto trac") du lien donné plus haut, il y a ceci : [https://fedorahosted.org/presto].
Dommage qu'il n'y aie pas encore de repo test pour ppc; je n'ai plus qu'à attendre F9.-
[^]Re: bsdiff...
-
-
[^]Re: bsdiff...
Posté par GeneralZod () le 18/01/2008 à 10:45. (lien). Évalué à 2.Sur le site de Presto, J. Dieter maintient un dépôt contenant les deltarpm par rapport à fedora-updates.
https://fedorahosted.org/presto
-
-
-
-
[^]Re: bsdiff...
Posté par Olivier Thauvin (page perso, ) le 17/01/2008 à 19:22. (lien). Évalué à 2.Parce que c'est très lourd à gérer:
- pour aller de la version 1 à 2 il te faut 2-1
- pour aller de la version 2 à 3 il te faut 3-2
- pour aller de la version 1 à 3 il te faut 3-1
Et plus il y eu de version d'update proposé, plus ça se complique. A l'arrivée c'est vite ingérable.
Il semble que Suse y arrive cependant.-
[^]Re: bsdiff...
Posté par chl (page perso, ) le 17/01/2008 à 19:57. (lien). Évalué à 5.- pour aller de la version 1 à 3 il te faut 3-1
Ou bien 2-1 et 3-2, qui existent déja normalement.
Car pour n versions mieux vaut n - 1 deltas, que n(n-1)/2 :)
-
[+] SOUS MAC ?
Cette page a été générée par Templeet en 0.3136s (dont 0.0791 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.