Mandrake, RedHat et SuSE certifiées LSB

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes :
0
19
août
2002
Linux

Les distributions GNU/Linux Mandrake, Red Hat et SuSE viennent d'être certifiées LSB (Linux Standard Base) par le Free Standards Group.



« L'objectif de la LSB est de développer et de promouvoir un ensemble de standards permettant d'améliorer la compatibilité entre les systèmes Linux (et d'autres systèmes similaires), ainsi que de permettre aux applications de fonctionner sur tout système s'y conformant. » (traduction libre du premier paragraphe de la FAQ)



Note du modérateur : j'ai rajouté le lien sur les produits certifiés qui détaille les versions testées.

Aller plus loin

  • # Debian

    Posté par  . Évalué à 1.

    Cela laisse croire que les systèmes de paquets sympas ne seront pas Unix-standardisés...

    • [^] # Re: Debian

      Posté par  . Évalué à 10.

      Mais non faut pas etre negatif comme ca, pis c'est pas le systeme de package .deb qui est remis en question ,c'est plus la standardisation des donnees dans /etc par exemple, ou la facon de lancer les demons.

      Si y'a pas un effort de standardisation de tout ca, on n'aura des produits 'pro' supportes que sur certaines distros, paske les boites n'auront pas envie de supporter toutes les fantaisies non communes a toutes (e.g. le script pour l'adsl speedtouch qui est monstrueux, paskil essaie de s'adapter a redhot,mandlake et debiam).

  • # deb rmp ...etc

    Posté par  . Évalué à -10.

    Hi,

    ferait mieux de standardiser les systems de paquets.

    Sinon, on va se retrouver comme en 1980, avec 80 unix tous incompatibles entre eux.
    Je sais ya alien et autres mais bon, un systeme de paquet et basta.

    • [^] # Re: deb rmp ...etc

      Posté par  . Évalué à 10.

      Ca n'arivera pas, simplement parceque Linux est Linux, dans les annees 80 les differnets Unix etaient differents les uns des autres, alros que sous les differentes distros Linux ce qui differe principalement, c'est les versions de lib ou de chemins, rien de bloquant avec une simple recompilation de l'appli

      Depending on the time of day, the French go either way.

    • [^] # Re: deb rmp ...etc

      Posté par  . Évalué à -10.

      mmh ça ne m'étonnerais pas que mandrake adopte une truc similaire au .deb d'ici quelques temps

      tout le monde est concient que rpm est ingérable à force, surtout à la vitesse où va mandrake.

      • [^] # Re: deb rmp ...etc

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

        tout le monde est concient que rpm est ingérable à force

        et le papier d'alu de la marmotte, il est ingérable aussi ??

      • [^] # Re: deb rmp ...etc

        Posté par  . Évalué à 8.

        Pourquoi rinventer la roue, les .deb existe depuis un certain temps, je crois, et il on fait leur preuve.

        Alors pourquoi Mandrake et d'autre distributions ne ce baserait pas sur Debian au lieu de RedHat ou encore d'essayer de faire leur propre système qui est incompatible avec les autres.

        Les gens ont bien plus de problème avec le rpm qu'avec les .deb.

        Voyer beaucoup de .deb qui sont fait pour juste une version de debian et qui ne fonctionne pas sur une autre version plus récente.
        EX: un rpm pour Mandrake 8.0 qui est pas compatible avec la 8.2 .

        Alors pourquoi la communauté GNU/Linux ne se base plus sur Debian, alors si la compagnie vient à fermer il sera toujours possible d'upgrader sa distribution avec le site de Debian tout en ayant pas à installer une nouvelle distribution.

        Et pour les gens qui ne trouve pas Debian assez à jour à leur goût, une Mandrake-Debian (oua le rêve)
        pourrait voir un serveur apt-get pour les truc plus à jour comme KDE 3 ou Gnome 2, ou compilé 686.

        PS: Sans vouloir faire un gros troll sur la Debian, car je suis nouveau sur Debian (avant j'avais Mandrke), je doit avouer que Debian et les Debian-Based (ex: Libranet) sont beaucoup mieux côté gestion des packages que tout les autres.

        Alors Pourquoi vouloir refaire le monde quand ça existe Déjà et que ça marche hyper bien?

        • [^] # troll debian à deux francs

          Posté par  . Évalué à 10.

          Les gens ont bien plus de problème avec le rpm qu'avec les .deb.
          C'est pas le format qui est en cause mais le fait que plusieurs distrib gérés par des personnes différentes utilisent le même format RPM.
          Une archive qu'elles soit DEB ou RPM te donne une liste de dépendance (d'ailleurs les deux formats codent approximativement les mêmes informations).
          Maintenant, pour que tout marche il faut aussi se mettre d'accord sur les noms des package ("g++" ou "gpp", "libgl" ou "mesagl" ou "mesa"), la numérotation à adopter pour les versions, ce qui doit constituer un package séparé : les includes je le mets dans un package développement ou je les ajoute au package de l'appli ?
          Il se trouve que comme le RPM est le format le plus répandu, il existe de nombreuses sources de paquets RPM mutuellement incohérente au niveau des dépendances.

          <Proposition>
          Au fait pourquoi pas abandonner et RPM et DEB et mettre les dépendances dans un simple fichier XML au sein d'une archive TAR contenant les sources.
          </Proposition>

          • [^] # Re: troll debian à deux francs

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

            <Proposition>
            Au fait pourquoi pas abandonner et RPM et DEB et mettre les dépendances dans un simple fichier XML au sein d'une archive TAR contenant les sources.
            </Proposition>

            Parce que tu vas finir par reinventer le .deb / le .rpm. Un .rpm peut se construire a partir d'un simple fichier "mon_package.spec" au sein d'une archive TAR contenant les sources, c'est exactement le systeme que tu proposes. Idem pour le .deb, qui peut se creer a partir d'un repertoire ./debian mis a la racine du package source, et qui contient les fichiers ad hoc.

            La seule valeur ajoutee serait l'emploi d'XML par rapport au format "fait maison" des .rpm et des .deb. Cela dit je suis pas sur que ce soit suffisant comme argument pour justifier l'introduction d'un nouveau systeme de package... L'emploi d'XML est pertinent lorsqu'on cree quelque chose de nouveau et/ou qu'on remplace un format binaire opaque, mais quand il s'agit de remplacer un format ouvert, largement repandu et dont les fichiers de conf sont lisibles, je vois pas trop l'interet.

            D'autre part, les directives contenues dans les fichiers rpm/deb ne se resument pas a de simples dependances. Elles contiennent des infos sur comment compiler l'appli (optimisations, repertoires d'installation,...), elles permettent aussi de lancer des scripts avant/apres l'installation, et parfois meme cela va jusqu'a patcher le source... Le probleme n'est pas vraiment simple en fait 8-)

          • [^] # Re: troll debian à deux francs

            Posté par  . Évalué à 5.

            Le nom des package n'est pas un problème, il suffit de bien définir ce que fourni le package ("provides" dans rpm, c'est lui que je connais).
            Dans ton exemple, tu crée disons un package qui s'appelle mesa et tu met dans sa liste de provides libgl mesa mesagl, ainsi si un autre package s'attend à trouver mesa ça parche, si un autre veut libgl ça marche aussi.
            Le problème c'est si ces définitions se multiplient (faut penser à tout), ou pire encore s'il y a des recouvrements (tel package fourni bien cette fonctionnalité, mais ce n'est en fait pas celle attendue par le package, elle a juste le même nom), d'où la nécessité d'une standardisation à ce niveau-là.

        • [^] # Re: deb rmp ...etc

          Posté par  . Évalué à 10.

          Pourquoi rinventer la roue, les .deb existe depuis un certain temps, je crois, et il on fait leur preuve.

          A priori, les RPM étaient là avant les DEB. Donc c'est Debian qui a réinventé la roue. Mais il faut dire à leur décharge qu'à l'époque les RPM avaint beaucoup de lacunes. Ça commence à s'arranger et les deux systèmes sont devenus à peu près équivalents.

          Il faudrait maintenant qu'ils essaient de converger vers un système commun qui prendrait le meilleur des deux mondes.

          • [^] # Re: deb rmp ...etc

            Posté par  . Évalué à 10.

            Je pense qu'il n'y a pas que le format des packages (et la pluralité des rpms) qui alimentent l'opposition entre les .deb et les .rpm. Il y a aussi le soin apporté à la conception de ces packages eux mêmes.

            Cela fait plusieurs fois que je lis ces derniers jours que les .deb permettraient d'avoir une distrib plus facile à maintenir que les autres. Je pense aussi que c'est du aux personnes qui préparent les packages et qui se cassent la tête parfois pour les faire correctement.

            En soit un package ne vaut rien. C'est la façon dont le contenu va s'intégrer dans la distrib qui compte réellement.

            Je pense pas que le rpm soit mauvais, mais qu'il bénéficie d'une mauvaise publicité suite à de malheureux packages mal fait...

            • [^] # Re: deb rmp ...etc

              Posté par  . Évalué à 5.

              il y aussi les .ebuild du systeme portage de la gentoo qui permet une mainteance aisée avec des scripts , les .ebuild, clair la aussi pas trop difficile a ecrire. En claire il y pas que les .deb et les .rpm. -concernant ceux ci d'ailleurs il est aisée d'avoir des packages rpm optimisé pour la distrib et le machine sans avoir a ecrire de .spec, ave le ./configure, make et checkinstall au lieu de make install

    • [^] # LIBERTE

      Posté par  . Évalué à 3.

      Pas d'accord. S'il n'y avait eu Redhat, le système de paquets serait justement la différence principale entre les distribution (la plus visible en tout cas)."Moi, je prend telle distrib parce que je veux installer ce programme et y a un paquet qui existe" est le principal argument pour les distrib RPM (même si apparemment, ça commence à foirer).
      tgz, rpm, deb, slp c'est un choix technique
      On ne peut pas enlever cette possibilité à ceux qui créent.
      D'ailleurs, ça ne devrait pas entrer en ligne de compte dans un standard. Le standard est censé être pour permettre aux applications de s'exécuter un peu partout. C'est un environnement de runtime (non?). A la limite, je suis extrêment content qu'il y ait l'arborescence (FHS), pas trop besion de parler de la compatibilité noyau ou libc. Mais le système de paquet n'entre pas en ligne de compte pour l'exécution.
      Et qu'il y ait autant de formats de paquets que possible!

      • [^] # J'ai oublié ...

        Posté par  . Évalué à 1.

        En plus, la compatibilité RPM risque de finir par être nuisible. Il n'est pas question que j'installe un rpm sur ma Debian avec rpm. Ca foutrait un souk pas possible : y aurait des fichier sous /usr qui ne seraient pas répertoriés dans la base de donnée dpkg! Et comment savoir si des fichiers ne seraient pas écrasés (dpkg empêche ça - ou au moins prévient quand ça arrive). Du genre :
        - j'installe rpm
        - rpm -(?) paquet.rpm
        - tient, nouvelle version (ou je veux supprimer)
        - je réinstalle rpm (eh oui, je l'ai viré à un moment)
        - je désinstalle le paquet
        - je désinstalle rpm

        Mieux vaut encore utiliser alien. Je préfèrerait même recompiler et faire un paquet debian. Même si mon paquet est un peu foireux, ça sera toujours mieux que ce mélange infâme.

        Ce qui me fait rire, c'est que la Debian est la plus gênée pas la LSB, alors qu'elle était très impliquée dans la FHS et était plus ou moins la distribution de référence à ce moment là. Ils peuvent dire merci aux concepteurs des standard qu'ils ont tant aidés.

        • [^] # Re: J'ai oublié ...

          Posté par  . Évalué à 1.

          Le FHS (file hierarchy standard), n'a malheureusement pas rencontré le même succès auprès des distributeurs.

          Il y a deux façons pour une entreprise de suivre les standards : s'y conformer, ou se démerder pour que le standard suive son implémentation à elle. Le FHS avait un inconvénient :)

          Au fait, qui a changé : RH ou SUSE ?

          TH.

  • # Pour Debian un espoir?

    Posté par  . Évalué à 10.

    Ici http://www.linuxdevices.com/news/NS4266194021.html(...) on peut lire LinuxDevices.com received an earlier announcement indicating that the following six additional distributions were certified, but apparently these are in process and not yet certified: Caldera, Debian, MontaVista, SOT, Sun, and TurboLinux..
    Soit en tout 9 distributions dont Debian et son système de paquetage qui seraient certifiées en tout, mais dont le processus est encore en cours.
    Croisons les doigts :-)

    • [^] # Re: Pour Debian un espoir?

      Posté par  . Évalué à -10.

      Pourquoi ne pas faire un systeme de packages qui prend les avantages des deux ?

      Ou alors pourquoi ne pas standardiser les deux et creer un outil qui sache traiter les deux systemes de packages.

      Y a bien des apt sous certaines distribs RPM, ça doit pas etre impossible ça !

      • [^] # Re: Pour Debian un espoir?

        Posté par  . Évalué à 3.

        apt agit dans ces cas là comme une surcouche à rpm. Il n'y a pqs réellement de pont entre les deux mondes.
        Sous debian :

        deb <-- dpkg <--apt
        ou
        deb <-- dpkg <-- dselect ( <-- apt eventuellement)

        sous mandrake je suis moins au courant
        rpm <-- urpmi <-- apt non?

        Il n'y a pas vraiment de factorisation. apt ne sert qu'aux sélections de package et obtention à partir des sources (locales ou pas)

        • [^] # Re: Pour Debian un espoir?

          Posté par  . Évalué à 4.

          Euh c'est plutot comme ca :

          debian:
          deb <-- dpkg <-- apt
          deb <-- dpkg <-- apt <-- dselect
          deb <-- dpkg <-- dselect

          mandrake:
          rpm (le format) <-- rpm (le logiciel) <-- urpmi

          red hat:
          rpm (le format) <-- rpm (le logiciel) <-- apt-get

          • [^] # Re: Pour Debian un espoir?

            Posté par  . Évalué à 1.

            > deb <-- dpkg <-- apt <-- dselect Argg! C'est vrai...

          • [^] # Re: Pour Debian un espoir?

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

            note : apt existe aussi sous mandrake Comme disait Samuel, il devrait être possible à apt de gérer une méta-base de paquets composés de deb et de rpms, vu l'avancement du portage de Connectiva. Maintenant, il faut faire gaffe à ce que ce soit pas trop le bordel, et aucune distrib n'aurait envie de supporter deux formats de packages différents, en assurant qu'ils sont totalement interchangeables.... Je pense très humblement qu'il y aura toujours des imcompatibilités entre packages de différents distributeurs, tout simplement parce que les distributions sont différentes. Et personne n'a envie de se retrouver avec une distrib unique.

  • # j'ai choisi mon Lsb a moi...

    Posté par  . Évalué à 1.

    c'est linux SLACKWARE based ^^)

    -1 je... --->[]

    • [^] # Autant que je sache...

      Posté par  . Évalué à 1.

      ... elle est 'LSB compliant' à défaut d'être 'LSB certified'. Cela dit, même chose pour moi. J'aime bien ces discussions sans fin sur 'mes deb sont mieux que tes rpms'. Je suppose que ca ne peut que faire rire un utilisateur de Slackware qui ne télécharge que des sources et qui gère soi-même ses dépendances quand './configure' lui signale un manque. :-) Bah! Installons nous confortablement das notre fauteuil en regardans tous ses packagers fous se disputer sur le meilleur système de package, tout en surveillant du coin de l'oeil la bonne avancée de notre compilation du dernier xine... :-) Cordialement,

Suivre le flux des commentaires

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