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é.
Aller plus loin
- rpm5.org (16 clics)
- l'annonce de la sortie de rpm5 (2 clics)
# R ?
Posté par manatlan (site web personnel) . Évalué à 6.
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 ?
Posté par arapaho . Évalué à 2.
[^] # Re: R ?
Posté par Cheneson Cyril . Évalué à 2.
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 ?
Posté par Kangourou . Évalué à 5.
[^] # Re: R ?
Posté par FReEDoM (site web personnel) . Évalué à 2.
c'est un acronyme récursif
[^] # Re: R ?
Posté par Nicolas Legrand (site web personnel) . Évalué à 10.
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 ナイコ (site web personnel) . Évalué à 1.
[^] # Re: R ?
Posté par Calim' Héros (site web personnel) . Évalué à 0.
[^] # Re: R ?
Posté par Anonyme . Évalué à 0.
[^] # Re: R ?
Posté par alouali (site web personnel) . Évalué à 0.
[^] # Re: R ?
Posté par IsNotGood . Évalué à -2.
[^] # Re: R ?
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: R ?
Posté par beagf (site web personnel) . Évalué à 8.
- 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 (site web personnel) . Évalué à 1.
[^] # Re: R ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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 . Évalué à 7.
# Les distributions?
Posté par ʭ ☯ . Évalué à 2.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Les distributions?
Posté par BAud (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 5.
# Non évènement
Posté par patrick_g (site web personnel) . Évalué à 10.
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 . Évalué à 3.
Greg De Koenigsberg résume très bien la situation.
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 . Évalué à 5.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 4.
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.
L'article auquel tu fais référence en parle.
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 . Évalué à -2.
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 (site web personnel) . Évalué à -5.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 2.
http://trainofthoughts.org/blog/2008/01/06/rpm5-vs-rpm/
[^] # Re: Non évènement
Posté par Olivier Thauvin . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 3.
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 ZeroHeure (site web personnel) . Évalué à 3.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Non évènement
Posté par nimnim . Évalué à 5.
> 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 . Évalué à 1.
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 . Évalué à 3.
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 . Évalué à 5.
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 . Évalué à 1.
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 . Évalué à 4.
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 . Évalué à 2.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 Maclag . Évalué à -1.
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 . Évalué à 2.
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 . Évalué à 3.
C'est comme perl quoi.
[^] # Re: Non évènement
Posté par briaeros007 . Évalué à 3.
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)
[^] # Re: Non évènement
Posté par IsNotGood . Évalué à 0.
C'est lent comment ?
J'ai fait un test avec un machine virtuelle (installe mini-mini, kvm en full-virtualisation, périphérique loopback).
Moins de 2 minute pour 184 Mo compacté.
Il y a peut-être plus rapide, mais plus rapide je m'en fous.
[^] # Re: Non évènement
Posté par Étienne . Évalué à 2.
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 :
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 . Évalué à 1.
[^] # Re: Non évènement
Posté par Étienne . Évalué à 1.
Merci
Etienne
[^] # Re: Non évènement
Posté par lezardbreton . Évalué à 5.
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 . Évalué à 4.
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 . Évalué à 2.
[^] # Re: Non évènement
Posté par vladislav askiparek . Évalué à 0.
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 . Évalué à 1.
df avant/après :
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 . Évalué à 2.
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.
[^] # Re: Non évènement
Posté par IsNotGood . Évalué à 2.
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 . Évalué à 0.
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"...
[^] # Re: Non évènement
Posté par - - . Évalué à 1.
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 . Évalué à 3.
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é.
[^] # Re: Non évènement
Posté par briaeros007 . Évalué à 1.
Et la version "cdrom" , te propose aussi d'aller vérifié les maj lors de l'install (toujours avec une liste de miroirs officiels).
[^] # Re: Non évènement
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 ?
[^] # Re: Non évènement
Posté par _seb_ . Évalué à 4.
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.
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 . Évalué à 1.
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 Étienne . Évalué à 1.
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
Posté par IsNotGood . Évalué à 1.
Par contre, il ne faut pas croire que ça va tout accelérer.
[^] # Re: Non évènement
Posté par briaeros007 . Évalué à 2.
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;))
[^] # Re: Non évènement
Posté par - - . Évalué à 3.
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...
Posté par karteum59 . Évalué à 4.
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 . Évalué à 1.
Suse l'a fait (ou le fait toujours).
Fedora va le faire :
http://fedoraproject.org/wiki/Releases/FeaturePresto
[^] # Re: bsdiff...
Posté par _seb_ . Évalué à 1.
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 . Évalué à 2.
D'ailleurs j'utilise Presto depuis Fedora 7 et ça marche super bien.
[^] # Re: bsdiff...
Posté par IsNotGood . Évalué à 1.
[^] # Re: bsdiff...
Posté par benja . Évalué à 1.
Dommage qu'il n'y aie pas encore de repo test pour ppc; je n'ai plus qu'à attendre F9.
[^] # Re: bsdiff...
Posté par IsNotGood . Évalué à 1.
C'est la honte pour moi, mais merci :-)
[^] # Re: bsdiff...
Posté par GeneralZod . Évalué à 2.
https://fedorahosted.org/presto
[^] # Re: bsdiff...
Posté par Olivier Thauvin . Évalué à 2.
- 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 (site web personnel) . Évalué à 5.
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 ?
Posté par adam0509 . Évalué à -3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.