Interview de Mike Hearn, de Autopackage.org

Posté par  . Modéré par Xavier Antoviaque.
Étiquettes :
0
7
mar.
2003
Linux
Newsforge a interviewé Mike Hearn, le développeur principal du projet autopackage.

Autopackage est un projet visant à faciliter la gestion des paquetages/dépendances sous Linux. L'intéret principal d'autopackage par rapport à RPM ou DEB est qu'il permet de gérer également les programmes compilés « à la main », ainsi que tous les paquets installés via RPM ou DEB. Actuellement, il est en plein développement mais gère la résolution des dépendances et l'installation locale (sans etre root) entre autres.

Le projet ne compte pas beaucoup de développeurs actuellement, donc je vous conseille d'aller jeter un coup d'oeil à l'interview et d'aider si vous maitrisez Bash (l'essentiel du projet est écrit dans ce langage).

Aller plus loin

  • # Re: Interview de Mike Hearn, de Autopackage.org

    Posté par  . Évalué à -10.

    Autopackage gère les dépendances entre RPM, DEB, tgz et compagnie? Ben ça doit être un beau bordel...

  • # Re: Interview de Mike Hearn, de Autopackage.org

    Posté par  . Évalué à 10.

    A propos de gestion des programmes compilés à la main, il y a aussi stow:
    http://www.gnu.org/software/stow/stow.html(...)

    Il est intégré à la Debian (mais je suppose sur d'autres distros).

    Indispensable pour toute distro packagée.

  • # Re: Interview de Mike Hearn, de Autopackage.org

    Posté par  (site web personnel) . Évalué à 10.

    Checkinstall est ton ami :)

    Il génère un rpm ou deb après une installation à la main. C'est beaucoup plus propre

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Interview de Mike Hearn, de Autopackage.org

      Posté par  (site web personnel) . Évalué à -2.

      Et il fait un excellent boulot sur ma LFS :)

      Le seul point noir est de devoir installer rpm mais vu qu'evolution le demande aussi ...

      Steph

    • [^] # Re: Interview de Mike Hearn, de Autopackage.org

      Posté par  . Évalué à 4.

      ... ou un tgz !

      pourquoi les tarballs slack sont toujours oubliés?
      N'oublions pas que checkinstall a d'abord été conçu pour les tarballs slackware, et juste après étendu aux deb et rpm.

      Je comtpe d'ailleurs apporter ma contribution pour les packages nba (quiz: qu'est-ce qu'un nba ? ..tic tic ..)

      • [^] # Re: Interview de Mike Hearn, de Autopackage.org

        Posté par  . Évalué à 3.

        Le format des paquets de Nasgaïa nan ? Bref encore un format de paquet en plus :( Perso je trouve ça nul de créer ENCORE un nouveau format de paquets....

        • [^] # Re: Interview de Mike Hearn, de Autopackage.org

          Posté par  . Évalué à 1.

          Ce n'est pas vraiment un nouveau format, puisque le principe de simplicité des tarballs slackware a été conservé.
          En fait, il s'agit d'une archive tar.bz2 au lieu d'un tar.gz.
          Dedans, on retrouve le même type de script d'installation que pour slack.
          Donc, c'est installable sans outil, contrairement aux formats de packages de d'autres distro: rpm, deb

          Mais comme d'habitude, chacun son point de vue, et si on dispose d'outils comme checkinstall ou autopackage qui gèrent l'ensemble, cela n'a aucune importance qu'il y ait 2 ou 10 formats différents : un outil saura tous les gérer.

      • [^] # Re: Interview de Mike Hearn, de Autopackage.org

        Posté par  . Évalué à 0.

        Le basket, ça su><e.

    • [^] # Re: Interview de Mike Hearn, de Autopackage.org

      Posté par  . Évalué à 0.

      Sauf erreur de ma part, checkinstall ne "gére" pas les rpm, c'est à dire qu'il ne prend pas en charge les paquets déjà paquagés. Donc le problème que j'ai rencontré est que toutes les dépendances des rpm natifs sont cassées. A savoir qui si on installe une librairie avec checkinstall, inutile d'espèrer qu'au prochain rpm -i le_paquet_ayant_besoin_de_cette_librairie tout ce passe bien.

      • [^] # Re: Interview de Mike Hearn, de Autopackage.org

        Posté par  . Évalué à 4.

        Tu te trompes. Checkinstall ne gère pas les dépendances du paquet que t'installes en terme de paquets. Ca fait que tu peux installer un paquet RPM crée avec checkinstall sans avoir les bonnes libs. Par contre, s'il fournit des libs, elles sont répertoriées et tu peux faire ton rpm -i le_paquet_ayant_besoin_de_cette_librairie

  • # Re: Interview de Mike Hearn, de Autopackage.org

    Posté par  (site web personnel) . Évalué à 10.

    Un point qui m'irrite toujours un peu dans ces discussions sur l'utilisation des packages, c'est de considérer uniquement l'aspect technique (une archive de fichiers et des méta-données), et d'oublier complément le travail d'intégration qu'il y a derrière. Un package, c'est aussi et surtout une partie d'un ensemble (une distribution) qui seul en assure la cohérence globale. Cette garantie d'intégration disparait à partir du moment ou l'on mélange des packages provenant de différentes sources, et aucune astuce technique ne pourra y remédier. Inciter à mélanger justement des packages provenant de différentes sources grâce à ce genre d'outils me laisse supposer un manque de réflexion sur les conséquences d'une telle politique de gestion de son système.

    • [^] # Re: Interview de Mike Hearn, de Autopackage.org

      Posté par  . Évalué à 1.

      Tout à fait d'accord. Je n'ai tjrs pas compris (peut être par manque d'information) pourquoi logrotate.deb depend de exim. Je n'aime pas exim. J'en veux pas. De plus, je ne connais pas le réel niveau de dépendance entre logrotate et exim (minime j'imagine mais je n'en suis pas certain). Résultat, vu que je n'ai pas envie de casser l'intégrité de mon système Debian, j'ai viré logrotate de mon cron.daily... Quelqu'un voit-il une solution à cela ?

      • [^] # Re: Interview de Mike Hearn, de Autopackage.org

        Posté par  . Évalué à 4.

        logrotate (enfin plutot mailx) à besoin d'un MTA, pas forcement d'exim.

        • [^] # Re: Interview de Mike Hearn, de Autopackage.org

          Posté par  . Évalué à 3.

          Package: exim Status: install ok installed Priority: important Section: mail Installed-Size: 1213 Maintainer: Mark Baker Version: 3.35-1 Replaces: mail-transport-agent Provides: mail-transport-agent Depends: libc6 (>= 2.2.4-4), libdb2 (>= 2:2.7.7-4), libident (>= 0.22-1), libldap2 (>= 2.0.2-2), libpam0g, libpcre3, cron (>= 3.0pl1-42) Recommends: netbase Suggests: mail-reader, eximon Conflicts: mail-transport-agent, exim-doc-html (<= 3.00-2), suidregister (<< 0.50) Je pense que ça répond parfaitement à la question... Il n'y aucune dépendance particulière qu'offre exim si ce n'est "mail-transport-agent", MTA.

  • # prendre en compte un soft installe a la main dans les dependances debian

    Posté par  . Évalué à 10.

    checkinstall fait du bon boulot, cependant il ne remplit pas les dependences.. http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html a cette url, on explique comment creer un fake package pour, par exemple installer un mta a la main et remplir la dependance mta (Provides: mail-transport-agent) ... pratique quand on veut installer un package qui depend d'un mta sans que debian en ait installé un...

Suivre le flux des commentaires

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