Forum général.petites-annonces Interview Jeff Johnson

Posté par (page perso) .
Tags : aucun
0
22
jan.
2005

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 (page perso) . Évalué à 3.

    Plutot que lacher 4 sujets dans le forum (qui disparaitront de la première page demain) ça serait mieux - amha - de passer une dépêche concernant le fosdem et incluant ces propositions de questions...
    • [^] # Re: fosdem

      Posté par (page perso) . Évalué à 4.

      Il y en a déjà 12, pas 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.
  • # Question à Jeff Johnson

    Posté par . Évalué à 1.

    NB : J'image que ceux qui collectent les questions voudraient de l'anglais. Malheureusement ma maîtrise de l'anglais ne me permet pas d'être sûr de ce que je dis :-) Si ça vous ennuie de traduire en anglais, oubliez ces questions.


    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 . Évalué à 1.

      > 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 ?
      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 . Évalué à 1.

        > Mieux vaut un outils simple

        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 (page perso) . Évalué à 1.

    Alors que le temps machine coûte de moins en moins cher et que les différentes options de configuration se font de plus en plus nombreuses, ne pensez-vous pas que l'avenir est à la compilation à la volée, comme c'est le cas dans le logiciel portage de Gentoo, plutôt qu'aux paquets exclusivement binaires ?
  • # Troll

    Posté par . Évalué à 2.

    What is your opinion on source-based distributions? What are the pros and cons of, on one hand a Gentoo source package with USE flags, and on the other hand a (set of) binary RPM(s)? Sure, i've asked the same question to Marius Mauch, a Gentoo/Portage developer :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.