Difficile

• [+] [^]Re: Difficile

  Posté par iug () le 04/01/2007 à 13:20. (lien). Évalué à -1.

  C'est bien là tout le problème.
  
  Dans les systèmes de paquets actuels, chaque paquet informe des capacités qu'il fournit, et de celles dont il a besoin.
  
  Il suffirait d'avoir un système de description des capacités standard, entre deb et rpm.
  
  Le problème c'est qu'il y a surement trop de boulets intaigristes pour y parvenir.

  • [^]Re: Difficile

    Posté par Aurélien Girard () le 04/01/2007 à 13:32. (lien). Évalué à 7.

    C'est un peu plus compliqué que ça.
    
    Les distributions proposent par exemple des granularités différentes : pour une même application (par exemple PHP) certaines vont par exemple fournir un gros paquet fourre-tout alors que d'autres vont proposer un paquet de base et un ensemble de paquets complémentaires (paquet de headers, pour tel ou tel module, etc.).
    Le choix de granularité est un choix fort de chaque distribution. Le leur retirer serait pénalisant.
    
    De manière plus générale, la valeur ajoutée apportée par chaque distribution est l'un des gros points forts du monde du logiciel libre. Tout standardiser en gommant leurs spécificités poserait le problème de la création d'une distribution de Linux/*BSD/autres unique qui proposeraient toutes la même chose.
    
    C'est un peu le même problème que le monde UNIX a pu affronter sauf que la compatibilité au niveau sources a déjà rendu la situation beaucoup plus saine.
    
    En tout cas, je souhaite bien du courrage au groupe de travail LSB qui s'attèle à un problème bien compliqué.

    • [^]Re: Difficile

      Posté par iug () le 04/01/2007 à 16:56. (lien). Évalué à 2.

      Il suffit de faire un système de description standardisé, que tel ou tel paquet fournisse telle ou telle capacité importe peu.
      
      Le problème c'est que pousser le découpage trop loin rendrait caduc les systèmes de capacités définis.
      
      Comme je disais, ce genre de choses nécessiterait un minimum de compromis entre les différents acteurs, et quand on voit les trolleurs que compte la communauté on est pas rendu, et c'est bien dommage. Il suffit de lire la suite des commentaires.
      
      Rendre inter-opérable deb et rpm est simple du point de vue technique, le choix de l'inter-opérabilité est un choix purement politique qui doit être fait par les développeurs principaux de Debian, Gentoo, Redhat, Mandriva, Ubuntu et Suse. Il suffirait que Debian et Redhat se mettent d'accord pour que les autres suivent.
      
      En tant qu'entreprise, Redhat y a tout intérêt. Debian a l'air de sortir de son extrémisme depuis peu (a mauvais escient je trouve, mais c'est le cas). On peut espérer que ça arrive un jour.
      
      J'ai du mal à comprendre que d'un côté la communauté gueule pour l'inter-opérabilité des formats de fichiers, et que d'un autre côté elle ne fait pas de même avec ses paquets.

    [^]Re: Difficile

    Posté par letsyl () le 04/01/2007 à 13:39. (lien). Évalué à 1.

    Ne serait-il pas possible d'avoir un paquet dans une sorte de format intermédiaire contenant les sources et une descriptions des bibliothèques requises, qui pourrait être transformé en rpm ou deb ou... adaptés à chaque distrib ? Cet outil de "transformation" serait à développer par la distrib.

    • [^]Re: Difficile

      Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 14:15. (lien). Évalué à 4.

      Alien ?

      • [^]Re: Difficile

        Posté par Barnabé () le 04/01/2007 à 18:59. (lien). Évalué à 1.

        Certainement pas alien.
        
        Alien travaille sur du binaire, et est incapable de transposer correctement les dépendances d'un système à l'autre.

    [^]Re: Difficile

    Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 14:23. (lien). Évalué à 4.

    À noter que le système Debian se trouve actuellement confronté (ou le sera très bientôt) à un problème de pertinences avec les outils de recherche se basant uniquement sur les noms et descriptions de paquets.
    À tel point qu'un développeur Debian, Enrico Zini, a décidé de mettre en application les travaux d'un mathématicien et bibliothécaire indien, Shiyali Ramamrita Ranganathan[1], avec DebTags[2]. Si le format RPM pouvait adopter ce système de tags (tout comme celui de Debconf d'ailleurs), il y a gagnerait en fonctionnalité et les deux systèmes y gagnerait en harmonie.
    Il n'y a pas qu'APT qui soit un bon système chez Debian.
    
    Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.
    
    [1]: http://fr.wikipedia.org/wiki/Shiyali_Ramamrita_Ranganathan
    [2]: http://debtags.alioth.debian.org/

    • [^]Re: Difficile

      Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 14:38. (lien). Évalué à 3.

      Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.
      
      Heu tu exageres un peu. RPM _supporte_ les dépendances sur des fichiers mais c'est très rarement utilisé et c'est fortement déconseillé.
      
      Je sais que sur Mandriva ca arrive dans un cas : quand ton cas contient des scripts, à la construction du package ca regarde les shebang et ca ajoute les interpretaurs comme dépendance. Quand l'interpréteur est présent sur la machine de build ca met une dépendance vers son package, sinon ca met vers le fichier. Donc on se retrouve avec une dépendance vers le fichier si on a oublié de mettre l'interpréteur comme dépendance de build et pas mis la dépendance à la main en ajoutant un ignore sur celle là.
      
      Le seul cas ou je ne sais pas comment éviter c'est dans les scripts de pre/post/... ou rpm met tout seul un require sur le fichier de l'interpreteur. La plupart des packages ont donc une dépendance vers /bin/sh, et en plus elle apparait plusieurs fois par packet (pour dire qu'on a besoin de lui en pre, en post, ...).
      
      Sur les 1789 installés sur ma machine :
      [pterjan@plop tmp]$ rpm -qa --requires | grep / | sort | uniq -c | sort -nr
      969 /bin/sh
      878 /sbin/ldconfig
      41 /sbin/install-info
      26 /usr/sbin/update-alternatives
      8 /usr/bin/perl
      4 /sbin/chkconfig
      3 /usr/sbin/groupadd
      3 /bin/awk
      3 /bin/ash
      2 /usr/sbin/update-ldetect-lst
      2 /usr/bin/tr
      2 /usr/bin/python
      2 /etc/pam.d/system-auth
      2 /etc/init.d
      2 /bin/sed
      1 /usr/share/autotools/ac-wrapper.pl
      1 /usr/sbin/useradd
      1 /usr/sbin/glibc-post-wrapper
      1 /usr/sbin/chkfontpath
      1 /usr/sbin/arping
      1 /usr/bin/run-parts
      1 /usr/bin/ruby
      1 /usr/bin/rrdcgi
      1 /usr/bin/env
      1 /usr/bin/cmp
      1 /usr/bin/chage
      1 /sbin/service
      1 /sbin/pidof
      1 /sbin/ip
      1 /sbin/fuser
      1 /etc/libuser.conf
      1 /bin/touch
      1 /bin/rm
      1 /bin/grep
      1 /bin/gawk
      1 /bin/egrep
      1 /bin/csh
      1 /bin/bash
      
      
      Quelques un sont des bugs mais la plupart ne sont que du bruit vu que c'est fourni dans le basesystem.

      • [^]Re: Difficile

        Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:15. (lien). Évalué à 2.

        J'exagère à peine : il n'y a qu'à regarder les require de la majeure partie des paquets RPM. Il suffit souvent de disposer du fichier adéquat pour que le RPM accepte de s'installer. Ce n'est pas simplement rare, c'est largement utilisé.
        Et quand on donne le choix aux utilisateurs, c'est comme des électrons, ils choisiront le chemin le plus court (comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).

        • [^]Re: Difficile

          Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 15:25. (lien). Évalué à 3.

          Ben justement j'ai regardé tous les packages de ma machine. Et il ne suffit pas que le fichier existe pour que le rpm accepte de s'installer, il faut qu'il soit fourni par un rpm installé !
          La dépendance ne se fait pas sur la présence de fichiers sur le système, c'est juste que en quelque sorte les rpm provident tous les fichiers qu'ils contiennent. rpm n'utilise que sa db pour résoudre les dépendances, pas la présence physique de fichiers...
          
          [root@plop SPECS]# rpm -ivh /home/pterjan/rpm/RPMS/i586/test-1-1mdv2007.1.i586.rpm
          erreur: Dépendances requises:
          /tmp/foo est nécessaire pour test-1-1mdv2007.1.i586
          [root@plop SPECS]# touch /tmp/foo
          [root@plop SPECS]# rpm -ivh /home/pterjan/rpm/RPMS/i586/test-1-1mdv2007.1.i586.rpm
          erreur: Dépendances requises:
          /tmp/foo est nécessaire pour test-1-1mdv2007.1.i586
          

          • [^]Re: Difficile

            Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:34. (lien). Évalué à 2.

            Hummm, au temps pour moi, c'est à la génération du paquet RPM qu'il exploite le ldd et les shells utilisés. Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.

            • [^]Re: Difficile

              Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 15:44. (lien). Évalué à 2.

              Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.
              Oui c'est pourquoi il existe des systèmes de build. SUSE en a un, Mandriva aussi, je suppose que Fedora aussi mais je ne sais pas.
              Tu donnes un src.rpm ou un spec + des fichiers sources et ca te rebuild et check le package avant de l'uploader.
              Celui de Mandriva actuellement, tu commites tout dans le svn et quand ton package te parait OK tu demandes à ce qu'il soit uploadé, ca sort les trucs du svn, genere un chroot, installe les dependances de build et génère le package. Si tout c'est bien passé en i586 et x86_64 et que rpmlint n'indique pas d'erreur bloquante, c'est uploadé.

              • [^]Re: Difficile

                Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:54. (lien). Évalué à 4.

                Et ce que fait également Debian avec son réseau de buildd pour ses 11 architectures.

          [^]Re: Difficile

          Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 15:40. (lien). Évalué à 2.

          comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).
          Et j'avais oublié de répondre à cette partie.
          Ca serait con de faire un ldd à la main pour ajouter des dépendances vers des fichiers quand mieux est déjà fait automatiquement.
          C'est fait lors du build du rpm par des scripts d'ajout de dep automatique, et ils mettent pas le nom de fichier de la lib mais son soname. Quand on package des libs ça ajoute aussi automatiquement la fourniture du soname des libs inclues dans le package (les dépendances vers les modules perl sont aussi automatiques ainsi que quelques autres choses...)
          
          Donc pourquoi les gens s'embeteraient ils à faire à la main des dépendances vers des fichiers plutot que d'avoir de dépendances automatiques propres ?

  [^]Re: Difficile

  Posté par Laurent Pointal (page perso, ) le 04/01/2007 à 15:07. (lien). Évalué à 2.

  Pour ce qui est de la problématique des dépendances, un logiciel devrait venir avec tout ce qui lui est nécessaire et qui n'est pas défini par la LSB. Il serait possible d'avoir quelques cas très limités où des applications pourraient dépendre d'autres composants.

  
  
  Donc les dépendances sont relatives à ce qui est défini dans la LSB, pour le reste, faut packager avec l'application.
  
  Ca risque de faire de gros packages, des duplications de librairies sur la machine, une utilisation plus importante de la mémoire... mais ça retire le "dll hell" - d'ailleurs il me semble que c'est sur cette voie que se sont lancés MacOS et Windows.

  --
  (pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)

  • [^]Re: Difficile

    Posté par Michel Galle () le 04/01/2007 à 16:00. (lien). Évalué à 6.

    Hormis le fait qu'os X est contrôlé par une seule entité (apple) :
    
    mac os X met à disposition un "framework" de développement très complet
    
    (le fameux "cocoa" et sa myriade de kit/core associés et Carbon)
    
    du coup, c'est très rare qu'un développeur sur os X ait subitement besoin d'une bibliothèque exotique
    
    quand c'est le cas, il est en effet d'usage de l'intégrer DANS le "bundle" de l'application
    (une application os X est un dossier qui peut contenir en plus du binaire des éventuelles bibliothèques, icones, etc)
    
    il arrive donc que des programmes os X intègrent la même bibliothèque populaire parce qu'Apple ne propose rien encore d'équivalent. Un cas classique c'est quand les développeurs veulent imiter un aspect des logiciels d'Apple qu'Apple n'a pas encore standardisé dans os X.
    
    dans les faits c'est rare (cocoa/carbon est tout de même très complet) et d'expérience, je n'ai pas ressenti que les programmes Mac prenaient une taille démentielle en comparaison de ceux de Linux.
    Cela dit, si vous en êtes encore à compter les octets, oui os X n'est pas optimisé pour économiser le disque dur, mais conçu pour simplifier la vie des utilisateurs et des développeurs sans pour autant tomber dans un délire à la windows.
    
    il faut bien réaliser qu'apple ,à chaque version d'os X, a agrandit "cocoa" , pour que tous les besoins des créateurs de programmes soient couverts. du coup, les développeurs n'ont pas eu besoin de partir dans le "dll hell" de windows.
    
    un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc
    
    
    (j'ai utilisé le terme "cocoa" dans son sens le plus large, les puristes sépareront peut être Webkit, webcore , core-data, core-image, core-bidule etc de "cocoa" , mais dans la pratique , le tout forme une plateforme couvrant presque tous les usages ce qui limite le besoin d'une gestion de paquetages provenant de multiples sources)
    
    
    bref, vla pourquoi os X n'a pas dégénéré en dll hell malgré son manque d'un véritable système de paquetage et dépendance.

    • [^]Re: Difficile

      Posté par Gof (Jabber id, page perso, ) le 04/01/2007 à 17:13. (lien). Évalué à 4.

      un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc

      
      
      Bha KDE fait ça.
      
      Qt et les kdelibs fournissent un "framework" de développement très complets.
      
      Les programme kde n'ont en général pas besoin d'autres dépendances.