c'est comme les formats de prises électrique, si tu en as plusieurs c'est le bordel pour installer tous ensemble
Faut être tordu pour 'installer des prises US en France et vice versa, ou alors savoir exactement ce que l'on fait.
franchement les .deb et .rpm sont grosso-modo équivalent
C'est ce qu'essayent de faire croire red hat et mandrake. Suffit de comparer les page de man des differents systèmes pour s'appercevoir que le rpm et ses outils associés sont derrière le système debian. Enfin bon, ca va troller (sans moi) cherie.
le but c'est d'avoir des OS qui sont le plus facilement administrable
Avec une techno de 1997 ?
[installshield si... et si... et si...] cela aurait été une bonne idée de l'utiliser
Quand bien même il repondrait à toutes ces conditions... Ligne de commande vs GUI... troll interminable en perspective.
: comme cela les projets multi-plateformes n'aurait eu qu'un seul outil de packaging a utiliser
Bein non... mois je prefère la ligne de commande pour les fonctions install / update / desinstall / reinstall / reconfigure / upgrade / downgrade(si !)
il est plus rapide de taper urpmi toto
oui, un peu plus qu' apt-get install toto....
Tu as des actions mandrake ? :o)
On y apprend que ca s'appuie sur une versions des rpm de 1997. Avec "quelques" limitations:
- Packages may not use RPM triggers
- Packages may not depend on the order in which scripts are executed (pre-install, pre-uninstall, &c), when doing an upgrade
- Some versions of RPM may produce packages which contain extensions or modifications to the RPM package format beyond what has been documented in the appendix of the Maximum RPM book. An LSB-conformant package must not contain any of these extensions
- The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages
Enfin bon, la section package dit juste qu'une distrib "LSB" ne doit pas forcemment avoir un format rpm, en revanche, elle doit avoir un mecanisme pour installer des packages "LSB" (rpm de 1997 sans fioriture)
Il y a des trucs beaucoup plus interessant dans la LSB ( http://people.debian.org/~joeyh/lsbtest/current/(...) ), et je rejoins le post auquel tu reponds, en disant qu'ils aurraient du s'abstenir de s'interesser au format de package. Pourquoi:
- Ils ont tiré leur standard vers le bas en prenant le plus petit denominateur commun (du coup, en excluant le .deb)
- Quelqu'un qui a aujoud'hui le choix d'installer le package de sa distrib ou un rpm de 97 "LSB copain", je pense qu'il va prendre le package de sa distrib quel que soit son format de package.
- Pour un editeur, il ne devrait ne pas s'occuper des histoires de dépendances/conflit _avec des packages_. c'est le role du packageur, qui lui, connait sa/ses distribs. Ce qui interesse l'éditeur, c'est que les differentes distribs, interagissent de la même façon avec son soft.
[^] # Re: Superbe merde
Posté par Gloo . En réponse à la dépêche Drivers ATI pour Linux. Évalué à 1.
Faut être tordu pour 'installer des prises US en France et vice versa, ou alors savoir exactement ce que l'on fait.
franchement les .deb et .rpm sont grosso-modo équivalent
C'est ce qu'essayent de faire croire red hat et mandrake. Suffit de comparer les page de man des differents systèmes pour s'appercevoir que le rpm et ses outils associés sont derrière le système debian. Enfin bon, ca va troller (sans moi) cherie.
le but c'est d'avoir des OS qui sont le plus facilement administrable
Avec une techno de 1997 ?
[installshield si... et si... et si...] cela aurait été une bonne idée de l'utiliser
Quand bien même il repondrait à toutes ces conditions... Ligne de commande vs GUI... troll interminable en perspective.
: comme cela les projets multi-plateformes n'aurait eu qu'un seul outil de packaging a utiliser
Bein non... mois je prefère la ligne de commande pour les fonctions install / update / desinstall / reinstall / reconfigure / upgrade / downgrade(si !)
il est plus rapide de taper urpmi toto
oui, un peu plus qu' apt-get install toto....
Tu as des actions mandrake ? :o)
Puisqu'on parle de la LSB, je ne crois pas qu'il faille s'arreter au format des package, d'ailleurs la section en question est toute petite:
http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/swinstall.htm(...)
On y apprend que ca s'appuie sur une versions des rpm de 1997. Avec "quelques" limitations:
- Packages may not use RPM triggers
- Packages may not depend on the order in which scripts are executed (pre-install, pre-uninstall, &c), when doing an upgrade
- Some versions of RPM may produce packages which contain extensions or modifications to the RPM package format beyond what has been documented in the appendix of the Maximum RPM book. An LSB-conformant package must not contain any of these extensions
- The distribution itself may use a different packaging format for its own packages, and of course it may use any available mechanism for installing the LSB-conformant packages
Enfin bon, la section package dit juste qu'une distrib "LSB" ne doit pas forcemment avoir un format rpm, en revanche, elle doit avoir un mecanisme pour installer des packages "LSB" (rpm de 1997 sans fioriture)
Il y a des trucs beaucoup plus interessant dans la LSB ( http://people.debian.org/~joeyh/lsbtest/current/(...) ), et je rejoins le post auquel tu reponds, en disant qu'ils aurraient du s'abstenir de s'interesser au format de package. Pourquoi:
- Ils ont tiré leur standard vers le bas en prenant le plus petit denominateur commun (du coup, en excluant le .deb)
- Quelqu'un qui a aujoud'hui le choix d'installer le package de sa distrib ou un rpm de 97 "LSB copain", je pense qu'il va prendre le package de sa distrib quel que soit son format de package.
- Pour un editeur, il ne devrait ne pas s'occuper des histoires de dépendances/conflit _avec des packages_. c'est le role du packageur, qui lui, connait sa/ses distribs. Ce qui interesse l'éditeur, c'est que les differentes distribs, interagissent de la même façon avec son soft.
On ne peut pas dire qu'il y a foule sur http://www.lanana.org/(...) ( http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/pkgnameconv.h(...) )
Cela dit, la resolution de conflit avec nombre de passe fixé, franchement, C'est pas propre. Je garde mes .deb. Et toc !