Jeff Johnson, auteur de RPM, sera présent au FOSDEM cette année pour une conférence sur ce projet et sa vision des paquetages de l'avenir.
http://www.fosdem.org/2005/index/speakers/speakers_johnson(…)
Vous pouvez lui poser ici vos questions jusqu'au Dimanche 30 Janvier 2005 au matin. L'équipe du FOSDEM les intégrera alors dans l'interview qui lui sera envoyée puis publiée sur le site du FOSDEM.
# fosdem
Posté par j (site web personnel) . Évalué à 3.
[^] # Re: fosdem
Posté par Pascal Terjan (site web personnel) . Évalué à 4.
Dès que j'aurai tapé les 10 qui manquent ca sera annoncé en page principale :-)
J'ai préféré tout séparer pour éviter de devoir avoir trop de boulot de tri ensuite.
[^] # Re: fosdem
Posté par j (site web personnel) . Évalué à 4.
Bien joué, ça sera plus simple pour renvoyer vers les questions.
# Question à Jeff Johnson
Posté par morgendorffer . Évalué à 1.
RPM est relativement "bas-niveau", mais avec plein de fonctionnalités, et est là depuis longtemps. Il semble satisfesant (et tout cas pour moi). Par contre pour les outils de plus haut-niveau il y a pléthore de solutions : apt, yum, up2date, smartrpm, urpmi.
Pourquoi selon vous il n'y a pas de consensus qui se dégage pour les outils de haut-niveau, ou du moins pourquoi ils ne sont pas basés sur une résolveur de dépendance commun ?
RPM ne devrait-il pas fournir une résolveur capable de répondre aux exigences des outils de haut-niveau afin d'établir une standard de fait ?
[^] # Re: Question à Jeff Johnson
Posté par Olivier Thauvin . Évalué à 1.
Ca je peux répondre partiellement rapidement:
rpm est là avant tout pour vérifier l'intégrité de l'installation, et il s'efforce de le faire au mieux. Mieux vaut un outils simple avec une tache bien specifique que un tout en un qui marche mal.
Mais petit à petit rpm sait faire de plus en plus de chose, en ce moment Jeff Johnson code le support du rollback dans les transactions (cad revenir en arrière si ça marche pas). rpm fourni déjà au sein de son API des fonctions pour chercher les dépendances manquantes, il peut egalement chercher les dépendances dans une rpmdb annexe et les proposer.
C'est vrai que pouvoir utiliser le solveur interne serait un plus, mais il y a beaucoup à faire encore, surtout si il essaye de rester un tant soit peu compatible avec l'existant.
[^] # Re: Question à Jeff Johnson
Posté par fabb . Évalué à 1.
rpm n'est pas simple.
> en ce moment Jeff Johnson code le support du rollback dans les transactions
Déjà fait depuis longtemps. Il n'y a que up2date qui l'utilise.
> C'est vrai que pouvoir utiliser le solveur interne serait un plus
Yum l'utilise partiellement. Le problème est qu'un résolveur "complet" n'a pas sa place dans rpm. rpm ne peut décider de donner la priorité à tel ou tel repository ou de décider par lui-même de faire un downgrade pour satisfaire une requête d'un utilisateur ou de supprimer une librairie qui n'est plus utilisé. C'est le travail de produits externes et il n'y a pas de standard actuellement.
Par contre pour les dépendances dans une base rpm, il y a un standard et c'est le standard rpm (il n'y a pas le choix).
# Compilation vs paquets binaires
Posté par Zakath (site web personnel) . Évalué à 1.
# Troll
Posté par tgl . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.