LSB 1.1

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
4
fév.
2002
Linux
Le Free Standard Group vient de publier la version 1.1 de la LSB (Linux Standard Base).
Je rappelle que le but de la LSB est d'assurer une parfaite compatibilité entre les différentes distributions de Linux. Beaucoup de sociétés semblent vouloir l'adopter.
Un autre projet entamé concerne une internationalisation digne de ce nom pour notre OS favori.

Aller plus loin

  • # orho

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

    Une autre projet
  • # Bonne nouvelle

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

    C'est une excellente nouvelle que voila: il devenait en effet un peu hardu de passser tres vite de l'administration d'une red-hat a une slack puis a une debian... et ne parlons meme pas de la Suse. J'avais parfois un peu l'impression qu'on se tournait vers une sorte de sission, un peu comme les grands unices, avec les red-hat like d'un cote, et les autres de l'autre. C'est dommage car un admin linux devrait etre comme un poisson dans l'eu sur tous les OS a Pingouins quelle qu'en soit la distrib.
    Quand a l'internationalisation c'est aussi une tres bonne idee. Meme si il ne faut pas pousser trop loin: avec les infos de la carte reseau en francais, la moitie des firewall me chient a la gueule (desole pour la vulgarite mais c'est comme ca).
    • [^] # Re: Bonne nouvelle

      Posté par  . Évalué à 10.

      Tout a fait. Une bonne nouvelle, il y a a l'heure actuelle plus de distrib que d'Unix commerciaux .... difficiles de passer de l'une a l'autre "mais ou il est le fichier de config ..? "

      Concernant l'internationalisation, je suis aussi d'accord il faut faire super gaffe. J'ai deja essaye un solaris en francais ... snifff plus aucun script qui marche !!
      La solution est un bon coup de LANG=C - quand c'est installe comme il faut- mais quand meme.
      Apres les Y2K compliant on va avoir droit a un International Compliant :)

      RuZed
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 6.

        La solution est un bon coup de LANG=C - quand c'est installe comme il faut- mais quand meme.


        Pas quand même ; si tes scripts chient, c'est parce qu'ils sont mal écrits, c'est tout. On n'analyse pas un fichier de journalisation ou une sortie standard sans prépositionner la variable de LANG.

        C'est une très bonne chose que l'internationalisation ; cela va permettre un sacré coup de balais...

        PK
    • [^] # Re: Bonne nouvelle

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

      Oui c'est une bonne nouvelle.

      Mais ce n'est pas non plus une révolution. Il existe déjà une bonne base commune, c'est GNU et POSIX à tous les systèmes Unix/Linux.

      Déjà, que POSIX soit mieux suivie, ce serait pas mal, pour la portabilité et l'uniformité des systèmes Unix en général.

      Ensuite, ce n'est pas si difficile que ça de passer de RedHat à Debian. Pour un utilisateur, ça ne change presque rien, et pour un administrateur, il y a le manuel.
    • [^] # Re: Bonne nouvelle

      Posté par  . Évalué à 1.

      pour la traduction c'est clair c'est pas encor la joie... cf le probleme de top dans la LFS 3.0 :)
      sinon une base standard c'est bien mais maintenant les distribs se specialisent un peu plus chacune de leurs cotes et c'est peut etre pas plus mal de leurs laisser une certaine libertée de mouvement... apres tout c'est du logiciel libre :)
      cepeandant c'est vrai qu'il faut limiter les abus (qui a dit red hat?)
    • [^] # Re: Bonne nouvelle

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

      C'est clair que cela peut carrément aider d'avoir une démarche d'unification des configurations et des outils pour ce faire plutot que de se battre à coup de "Debian rulez pasque le fichier de conf il est pas pareil il est mieux".
      Concernant l'internalisation remarquons que la Mandrake, pour une install française, s'en tire remarquablement bien !
      Et pour les programmes de Firewall qui chient, c'est eux qui sont pas internationnalisés...
      On peut pas demander aux développeurs dans leur coin de satisfaire l'i18n... Le plus simple est alors de repasser en "LANG=C" pour ces programmes.
      • [^] # Re: Bonne nouvelle

        Posté par  . Évalué à 4.

        Je suis favorable à l'internationalisation des distribs et même si j'ai du mal à comprendre la configuration d'une Mandrake je reconnais que le support du français est plutôt réussi. Cependant les pages de man et les messages du shell en français çà me choque. Pourtant je ne suis pas une bête en anglais (570 au TOEFL) mais quand le message est en français je prend plus de temps à comprendre sa signification que lorsqu'il est en anglais, je suis peut être déjà un petit vieux qui n'aime pas qu'on change ses habitudes ;)
  • # Excellente nouvelle....

    Posté par  . Évalué à -2.

    Encore faudrait-il que ce standard soit suivi !
    Mais je pense que c'est une bonne chose. Ainsi, la LFS est très informée du sujet, et on peut déjà se composer un système "ausx petits oignons" en suivant les recommandations de la LSB.
    D'ailleurs, ça devrait permettre de créer des outils d'administration générique se basant sur ce standard. Ainsi, passer d'une distrib à une autre ne poserait pas de probs !
    Par ex, YaST développé par SuSE est un bon outil, dommage qu'il ne se repose pas sur des standards...pour l'instant, ça viendra peut-être (en tout cas, c'est à souhaiter !).
    • [^] # Re: Excellente nouvelle....

      Posté par  . Évalué à 10.

      YaST n'est pas libre, on ne peut pas le vendre dans une distrib commercial. Donc aucune chance qu'il devienne un outil générique sur toutes les distribs. Redhat, Mandrake, etc. n'ont pas le droit légalement de le distribuer.

      Le contraire s'est passé avec le RPM, développé par redhat. Il est libre et beaucoup de distribs l'ont adopté, ce qui en a fait un outil "standard".
      • [^] # Re: Excellente nouvelle....

        Posté par  . Évalué à 1.

        Je n'ai jamais prétendu le contraire, j'indiquait simplement qu'un outil de ce genre pour administrer un Linux serait le bienvenu, et que ce serait plus facile à développer avec une normalisation des fichiers de config.
  • # Debian et RPM

    Posté par  . Évalué à 10.

    Je vient de parcourir les spec de la LSB(1).

    A la section Package Format(2) on peut lire qu'une distrib LSB doit supporter l'installation avec RPM bien qu'elle ne doive pas absolument l'utiliser pour sa propre installation. Tout les noms de packages LSB doivent commencer par "lsb-", et être registés au près du Linux Assigned Names and Numbers Authority (LANANA).

    Je me demande comment debian va résoudre ce problème. Avec Alien ?


    Coté lib graphiques (l'éternel problème), on notera la présence de X11, OpenGL, ncurses. Donc pas de gtk+, QT ou autre toolkit de haut niveau.


    1. http://www.linuxbase.org/spec/(...)
    2. http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/swinstall.htm(...)
    • [^] # Re: Debian et RPM

      Posté par  . Évalué à 10.

      > A la section Package Format(2) on peut lire qu'une distrib LSB doit supporter l'installation avec RPM bien qu'elle ne doive pas absolument l'utiliser pour sa propre installation.

      [ snip ]

      > Je me demande comment debian va résoudre ce problème. Avec Alien ?

      Exact. Plus précisément, la distrib en question doit pouvoir utiliser le RPM v3 (les RedHat 7.X utilisent le RPM v4).
      J'ai cru comprendre a la sortie du LSB 1.0 que cela ne poserait pas de problèmes pour la Debian.
    • [^] # Re: Debian et RPM

      Posté par  . Évalué à 10.

      Perso, je ne pense pas que le format des paquetage soit essentiel, le principal problème est de pouvoir basculer facilement d'une distrib à l'autre. C'est donc principalement un problème d'emplacement de fichiers, de logiciel standard (par exemple est-ce que les scripts de démarrage doivent pouvoir être executés par n'importe quel shell POSIX ou bien est-ce qu'on accepte de la syntax spécifique à bash ou zsh).

      Mais de toute façon c'est assez compliqué de changer les habitudes, et à la fois essentiel et c'est un des grands défits du monde Linux, de prouver que malgré le travail collaboratif, et en dépit des opinions de certains, nous sommes capables d'assurer une certaine cohésion entre nos distributions.
    • [^] # Re: Debian et RPM

      Posté par  . Évalué à 6.

      Je me demande comment debian va résoudre ce problème. Avec Alien ?

      Meme pas besoin, en fait. Les développeurs Debian n'ont pas l'intention de laisser tomber les .deb et les outils qui vont avec. C'est pas seulement lié à apt-get, il y a aussi quelques trucs sympas dans le format .deb. Donc ca, ca n'a aucune chance de changer, et tous les packages fournis resteront des .deb à moins que la LSB fasse évoluer les RPM.

      Ce qu'il faut voir, c'est que le but de la LSB, c'est surtout de permettre à n'importe qui de créer un package, et que ce package soit installable sur n'importe quelle distrib conforme à la LSB.

      Les paquets Debian sont faits pour Debian. Il n'y a pas lieu d'exiger qu'ils soient conformes aux packages LSB, d'ailleurs la LSB ne le demande pas. Par contre ce qu'il faut, c'est que Debian (comme toute distrib souhaitant respecter la LSB) permette d'installer des packages LSB. Et ces packages là ne sont pas les packages des développeurs Debian, mais ceux de développeurs amont ou n'ayant pas leur logiciel dans la distrib.

      En fait c'est quasiment indépendant. Actuellement Debian fournit déja rpm. Gérer les packages LSB, c'est simplement avoir un outil permettant de les installer en respectant ce format RPM/LSB. Dans le détail, je simplifie surement (puisqu'il faut par exemple exprimer les dépendances), mais c'est l'idée : les packages LSB, c'est pour permettres aux développeurs de créer des packages de leurs logiciels, installables sur toute distrib. Ca ne concerne pas la distrib et son propre système de packages.
  • # J'attends de voir..

    Posté par  . Évalué à 3.

    Pour moi si la LSB est un succes un jour:
    -ca veut dire que je peux installer un RPM Suse sur une Mandrake.
    -que je peux installer un RPM facilement sur une Debian et continuer eventuellement avec un melange .deb et de RPM sans probleme.

    Et que a terme, on puisse avoir des RPM fait pour la LSB pas pour Mandrake, Suse, etc.

    Ca serait pas un mal!!
    • [^] # Re: J'attends de voir..

      Posté par  . Évalué à 7.

      A la base, la LSB c'est surtout fait pour que les logiciels propriétaires genre Oracle, puissent tourner sur n'importe quel Linux.

      Donc, en fait tu auras des RPM lsb, qui pourront s'installer sur toute distrib validée LSB, mais les RPM fournis par Mandrake, Redhat, SuSe continueront à etre spécifique à leurs distributions.

      De plus, la LSB est loin d'instaurer une uniformisation des fichiers de conf, puisque seuls quelques points sont définis. A chacun de choisir où placer les infos de la conf réseau, etc...
      • [^] # Suggestion pour unifier les .rpm et des .deb

        Posté par  . Évalué à 10.

        Il y a un truc que j'ai toujours trouvé améliorable dans le format des .RPM et des .DEB.

        Je m'explique : dans un package il y a deux choses des données (sources, binaires à installer, doc ...) et des métadonnées (nom du package, dépendances, mais aussi licenses, version ...).

        L'auteur d'un outil de gestion de package doit créer un moteur de gestion des dépendances, et suivant la logique adoptée par son moteur il choisira tel ou tel organisation des métadonnées pour décrire les dépendances : c'est ce qui limite la fonctionalité d'un ALIEN, il y a forcément perte d'information lors de la conversion puisque l'on en est réduit au plus petit dénominateur commun.

        Ma proposition : un package est en fait un simple fichier .tar contenant deux choses :
        - un "data.tar" pour les données..
        - un "metadata.xml" pour les métadonnées.

        Avantages :
        - au lieu de standardiser le fond (quelles métadonnées stocker), on ne standardise que la forme (tag XML à utiliser).
        Chaque outil de package reste donc libre d'utiliser son propre format de métadonnées (différent par exemple entre une Debian et une RedHat/Mandrake)
        - comme un fichier XML est un fichier texte il est facile de créer un package à l'aide d'outils standards (dejà le cas pour .deb)
        - extensibilité : le comportement par défaut du parser est d'ignorer les tags inconnus.
        Même si le nouveau tag n'est reconnu par aucun outil de gestion de package, il reste compréhensible par un humain (par exemple un tag "<LICENCE>GPL</LICENSE>")
        - possiblité de gziper le tar pour regagner la place perdue par le format texte.
        - possibilité d'écrire des outils d'importation/exportation entre le format XML et des format .deb ou .rpm sans perte d'information (contrairement à ALIEN) puisque le format XML peut-être choisi comme + grand dénominateur commun.

        On peut ainsi prendre un .DEB le convertir en XML, rajouter à la main les méta-informations manquantes puis le convertir en RPM et obtenir un RPM de qualité équivalente à un qui aurait été généré directement dans ce format.
        Idem pour le sens de conversion .RPM --> .DEB
        • [^] # Re: Suggestion pour unifier les .rpm et des .deb

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

          Tu peux aller jeter un coup d'oeil à http://jpackage.sourceforge.net/xml.php,(...) on avait commencé à utiliser ce système pour produires différents rpm à partir d'une même origine. Comme maintenant on fait des rpms uniques, et qu'il n'y a jamais d'interêt externe, on a laissé tomber, mais l'idée originelle était de s'affranchir d'un format particulier.
          • [^] # Re: Suggestion pour unifier les .rpm et des .deb

            Posté par  . Évalué à 1.

            j'ai rien compris, c'était quoi ton but à la base ?

            Convertir un genre "metadata.XML + data.tar" en RPM, c'est ça.

            Sinon, tu peux me montrer ta DTD ?
            • [^] # Re: Suggestion pour unifier les .rpm et des .deb

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

              >j'ai rien compris, c'était quoi ton but à la base ?
              Sortir un rpm mandrake (avec l'extension mdk et les trucs spécifique à mandrake) et un autre rpm redhat (sans extension et avec les trucs spécifiques à redhat) à partir du même tronc commun. Ou sortir un deb. Ou faire autre chose qu'un rpm, comme un graphe des dépendances, par exemple.

              >Sinon, tu peux me montrer ta DTD ?
              Il n'y en a jamais eu, puisque le principe a été abandonné avant d'être suffisament stable pour en faire une DTD. Par contre, tu as des documents dans ce format, ainsi que de feuilles de style dans le CVS.
              • [^] # Re: Suggestion pour unifier les .rpm et des .deb

                Posté par  . Évalué à 0.

                ...feuilles de style...
                comprends pas, tu générais quoi avec ta feuille de style, un autre format XML (où est l'intérêt ?), ou bien du texte pur pour derrière lancer un utilitaire qui "builde" le RPM

                Sinon, à mon avis ça vaudrait le coup de faire des DTD/Schémas pour chaque profil (RPM redhat, RPM Mandrake, DEB Debian ...) de façon à pouvoir vérifier qu'un "metadata.xml" est capable de générer un binaire RPM/DEB conforme (et avec toutes les extensions "proprios" obligatoires).
                • [^] # Re: Suggestion pour unifier les .rpm et des .deb

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

                  >comprends pas, tu générais quoi avec ta feuille de style
                  Le fichier spec.

                  >Sinon, à mon avis ça vaudrait le coup de faire des DTD/Schémas pour chaque profil (RPM redhat, RPM Mandrake, DEB Debian ...)
                  Ben non, un seul schéma, qui isole les métadonnées indépendantes (description, dependances, etc...), d'une partie valable pour rpm uniquement, d'une autre pour deb, d'une troisième pour autre chose, etc... Et éviter de normalise le contenu de ces parties spécifiques, pour garder une certaine souplesse.
                  <soft>
                  <description>
                  </description>
                  <rpm>
                  </rpm>
                  <deb>
                  </deb>
                  <autre_chose>
                  </autre_chose>
                  </soft>
                  • [^] # Re: Suggestion pour unifier les .rpm et des .deb

                    Posté par  . Évalué à 3.

                    un seul schéma...eviter de normalise le contenu de ces parties
                    justement le but c'est d'éviter les doublons alors si c'est pour avoir :
                    <rpm>
                    <desc>ceci est un soft qui fait le café</desc>
                    </rpm>
                    <deb>
                    <desc>ceci est un soft qui fait le café</desc>
                    </deb>
                    je vois pas l'intérêt !

                    pour garder une certaine souplesse.
                    Et alors, si un gars veut rajouter un nouveau tag qu'il le fasse !
                    Admettons que la debian ait une métadonnée "Licence" du programme qui ne soit par présent dans les RPM (c'est juste un exemple) :

                    <package>
                    <nom>biduleSoft</nom>
                    <version>1.0</version>
                    <license familly="BSD">X11</license> <!-- Ceci est un tag spécifique Debian -->
                    ...
                    </package>

                    après tu peut faire un schéma Debian qui valide ton "metadata.xml" seulement si le tag "license" est présent.

                    L'utilitaire de conversion en RPM ne reconnaitra pas ce tag et le sautera.
                    • [^] # Re: Suggestion pour unifier les .rpm et des .deb

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

                      >je vois pas l'intérêt !
                      Tu n'as pas compris mon explication précédente, je recommence
                      <soft>
                      <description>Ce soft fait le café</description>
                      <rpm>%setup</rpm>
                      <deb>%yam #yet another macro</deb>
                      </soft>

                      A partir de ceci, tu peux produire un spec pour rpm:
                      Description: ce soft fait le café
                      %setup

                      Et l'équivalent pour deb:
                      Description: ce soft fait le café
                      %yam #yet another macro

                      Il faut donc standardiser les métadonnées, mais pas les macros spécifiques, qu'on peut se contenter de recopier directement.
          • [^] # Les dépendances ne marchent pas....

            Posté par  . Évalué à 2.

            Le soucis principal est qu'on ne peut pas factoriser les dépendances, du moins directement dans le fichier xml, car biensur, les distributions n'ont pas la même hierarchie de paquetage.

            Une solution consisterait à aller taper dans le aclocal.m4 ou tout autre fichier permettant de faire un test d'environnement de compilation, puis de faire le chemin inverse des dépendances de fichiers vers les paquets (spécifiques à chaque distrib).

            Le fichier XML ne contiendrait alors que la section réellement factorisable entre tous les systèmes de paquetage.
  • # Les conf m'en fout pas mal et rpm ou pkg ou deb pareil !!

    Posté par  . Évalué à 1.

    Ce que je voudrais, c'est que les lib soit communes, qu'importe la façon de les mettre. Il n'y a rien de plus chiant que de courir d'une version de lib à l'autre pour faire tourner un truc en binaire compilé avec gcc xxx qu'on trouve pas facilement.
    Et même, si on compile sur sa bécane, on peut pas tout partager.

    Bon faut que j'installe la glibc 2.2.
    Le dicton du jour :

    D'abord backupe et brule quelques galettes

    Tout ça pour dire que la LSB, c'st pas mal !

Suivre le flux des commentaires

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