Source Linux.com
Ça faisait longtemps que le développement de RPM ne bougeait pas des masses, chaque distro l'utilisant ayant fini par maintenir sa propre version, en général dérivée de la 4.4.2. Tout le monde a donc été content après l'annonce de Red Hat il y a quelques mois de la reprise d'un effort de développement commun, via le site rpm.org.
Seulement voilà, si Red Hat est à l'initiative de RPM, son mainteneur de longue date est Jeff Johnson. Et celui-ci en a eu également assez de la stagnation du logiciel. Il vient donc de lancer un site qui claque, rpm5.org, pour rassembler la communauté RPM autour du développement de RPM 4.5 et RPM 5.
Cela fait donc deux efforts d'unification, l'un se basant sur RPM 4.4.2 présent dans sa distribution, l'autre sur RPM de base version 4.4.9. L'effort de Red Hat à été rejoint par Novell, tandis que Mandriva, cAos, et PLD ont rallié celui de Jeff Johnson.
Si les deux efforts en viennent à donner des programmes incompatibles entre eux, qui de RPM ou de RPM aura le dessus ? Moi je vous le dis, on n'est pas sorti de l'enfer.
Journal Le retour de RPM - Divergences sur la convergence
16
juin
2007
# on y est déja sorti en fait...
Posté par jeffcom . Évalué à 10.
damn ! on est plus vendredi !
~~>[]
[^] # Re: on y est déja sorti en fait...
Posté par B16F4RV4RD1N . Évalué à 2.
C'est où l'enfer déjà ? -----> []
en tout cas ils sont énervants à ne pas pouvoir trouver un terrain d'entente commun...
Ils parlent également de http://www.openpkg.org/ , je ne connaissais pas...
J'avais fait un petit journal au sujet de ce problème :
http://linuxfr.org/~farvardin/22989.html (quand même quelques 121 commentaires...), et j'avais évoqué de pouvoir trouver un format commun pour toutes les distributions. Quelqu'un avait fort justement rétorqué cela :
"Un programme utilise des librairies, et toutes les distrib n'ont pas les mêmes. (version, etc...)"
http://linuxfr.org/comments/768864.html#768864
je me demande si on ne pourrait pas reprendre l'idée de paquets depuis le début, c'est à dire de pouvoir définir un format d'empaquetage unique, à partir des sources, et que de là pouvoir les décliner en fonction des distributions (versions de bibliothèques spécifiques etc), en gros qu'il n'y ait qu'un seul squelette, qu'un seul travail d'empaquetage, sur lequel toutes les distributions pourraient bâtir plus ou moins automatiquement leurs paquets binaires.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: on y est déja sorti en fait...
Posté par Nerdiland de Fesseps . Évalué à 3.
[^] # Re: on y est déja sorti en fait...
Posté par Misc (site web personnel) . Évalué à 2.
Tu te voit dire "oui, on a trouvé le probléme à temps, mais on attends que XXX sorte le logiciel, et si XXX mets du temps, ben tant pis pour vous. et si jamais il a aussi rajouter des tonnes de trucs non testés et incompatible, c'est pas grave, on va mettre à jour aussi 2h avant la final"
Les patchs servent aussi pour les incompatibilités. Tu va encore une fois pas attendre que le dev installe une nouvelle version d'une lib si il veut pas ou n'a pas le temps, et une fois encore, attendre une nouvelle release fait perdre du temps. Si au lieu d'avoir un paquet prés à tester, tu attends une semaine ( cas trés favorable d'un upstream qui sort le tarball tout de suite ), ben tu as pris du retard.
Enfin, il y a des patchs pour les fonctionnalités. Et c'est demandé par qui, les nouvelles fonctionnaltiés ? Par les utilisateurs, qui au final font pression indirectement sur les distributions.
Il y a au final bien plus de patchs utiles et valides que de patchs qui posent probléme. Et les patchs sont souvent remontés upstream, quand il existe et qu'il les accepte.
[^] # Re: on y est déja sorti en fait...
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à -1.
Les patchs appliqués par certaines distrib sur les soft avant paquetage ne sont pas testés du tout (juste "ça se lance ?") faut pas pousser !
Alors mettre un lot des patchs sur un soft non testé à fond ou ne pas les mettre et devoir attendre la prochaine sortie du soft, je trouve qu'aucun des deux cas n'est bien. Mais dire que c'est super génial les distribs qui patchent à fond les softs je ne suis pas d'accord.
Après quand t'as un soucis avec le soft tu ne peux pas remonter de bugs au près des devs du soft car tu n'as pas une version officielle. Et je parle pas des bugs et autres joyeuseté que des patchs ajoutant ou modifiant des comportements apportent !
Je trouve ça important de pouvoir dire "j'ai le soft X version y.z" et d'être sûr de ce qu'il y a dedans !
[^] # Re: on y est déja sorti en fait...
Posté par M . Évalué à 3.
Oui les patchs c'est pas idéal, mais la pluspart du temps c'est difficile de faire sans.
[^] # Re: on y est déja sorti en fait...
Posté par Croconux . Évalué à 2.
# Fork pas très net
Posté par Aurélien Bompard (site web personnel) . Évalué à 3.
C'est bien que le développement se relance, et après tout comme tout est sous la même licence, rien n'empêche des échanges de codes.
Enfin, tout ça à cause de problèmes personnels... Un peu d'historique sur ce qui s'est passé : http://lwn.net/Articles/196523/
[^] # Re: Fork pas très net
Posté par ragoutoutou . Évalué à 3.
[^] # Re: Fork pas très net
Posté par Anonyme . Évalué à 1.
Ben si, il s'appelle rpm5. L'autre c'est rpm.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.