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
- La news sur ZDnet (4 clics)
- La news dans la LWN (bas de la page) (4 clics)
- L'annonce du Free Standards Group (3 clics)
# orho
Posté par Marc (site web personnel) . Évalué à -10.
[^] # Re: or<t>ho
Posté par Annah C. Hue (site web personnel) . Évalué à 0.
[^] # Re: or<t>ho
Posté par Marc (site web personnel) . Évalué à -2.
# Bonne nouvelle
Posté par - neuro (site web personnel) . Évalué à 10.
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 pfrenard . Évalué à 10.
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 freePK . Évalué à 6.
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 G. R. (site web personnel) . Évalué à 3.
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 kael . Évalué à 1.
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 VACHOR (site web personnel) . Évalué à 6.
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 ashram4 . Évalué à 4.
# Excellente nouvelle....
Posté par Gyro Gearllose . Évalué à -2.
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 Marc . Évalué à 10.
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 Gyro Gearllose . Évalué à 1.
# Debian et RPM
Posté par Marc . É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. 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 Emmanuel Seyman . Évalué à 10.
[ 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 Étienne . Évalué à 10.
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 #3588 . Évalué à 6.
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 reno . Évalué à 3.
-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 Thomas Poindessous . Évalué à 7.
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 Stephane JUTIN . Évalué à 10.
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 Guillaume Rousse (site web personnel) . Évalué à 1.
[^] # Re: Suggestion pour unifier les .rpm et des .deb
Posté par Stephane JUTIN . Évalué à 1.
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 Guillaume Rousse (site web personnel) . Évalué à 1.
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 Stephane JUTIN . Évalué à 0.
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 Guillaume Rousse (site web personnel) . Évalué à 3.
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 Stephane JUTIN . Évalué à 3.
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 Guillaume Rousse (site web personnel) . Évalué à 2.
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 Jean-Noël Avila . Évalué à 2.
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 Egidius . Évalué à 1.
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.