Comme programmeur, je conçois facilement qu'on doive compiler
tels fichiers avec tel version d'une librairie ou une meilleure
version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux
ne compileront jamais rien sur leur ordinateur et iront seulement
chercher des logiciels déjà compilés ? De ce point de vue, ne
faudrait-il pas revoir la façon de gérer ces dépendances quand on
installe un nouveau logiciel pré-compilé ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Kevin Denis
Le 15-07-2007, Denis Beauregard a écrit :
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Bin... apt-get va chercher le logiciel qui te manque; avec ce
programme vient une liste de dependances nommees. apt-get verifie recursivement si tout est la. S'il en manque, il va les chercher.
swaret t'installe un logiciel, puis il fait un ldd sur les binaires, va chercher les librairies non resolues, et eventuellement les installe.
rpm, ca doit ressembler pas mal a apt-get.
Que veux tu revoir dans cette facon de gerer les dependances? -- Kevin
Le 15-07-2007, Denis Beauregard a écrit :
Comme programmeur, je conçois facilement qu'on doive compiler
tels fichiers avec tel version d'une librairie ou une meilleure
version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux
ne compileront jamais rien sur leur ordinateur et iront seulement
chercher des logiciels déjà compilés ? De ce point de vue, ne
faudrait-il pas revoir la façon de gérer ces dépendances quand on
installe un nouveau logiciel pré-compilé ?
Bin... apt-get va chercher le logiciel qui te manque; avec ce
programme vient une liste de dependances nommees. apt-get verifie
recursivement si tout est la. S'il en manque, il va les chercher.
swaret t'installe un logiciel, puis il fait un ldd sur les binaires,
va chercher les librairies non resolues, et eventuellement les installe.
rpm, ca doit ressembler pas mal a apt-get.
Que veux tu revoir dans cette facon de gerer les dependances?
--
Kevin
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Bin... apt-get va chercher le logiciel qui te manque; avec ce
programme vient une liste de dependances nommees. apt-get verifie recursivement si tout est la. S'il en manque, il va les chercher.
swaret t'installe un logiciel, puis il fait un ldd sur les binaires, va chercher les librairies non resolues, et eventuellement les installe.
rpm, ca doit ressembler pas mal a apt-get.
Que veux tu revoir dans cette facon de gerer les dependances? -- Kevin
Denis Beauregard
Le Sun, 15 Jul 2007 19:47:48 +0000 (UTC), Kevin Denis écrivait dans fr.comp.os.linux.debats:
Le 15-07-2007, Denis Beauregard a écrit :
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Bin... apt-get va chercher le logiciel qui te manque; avec ce
programme vient une liste de dependances nommees. apt-get verifie recursivement si tout est la. S'il en manque, il va les chercher.
swaret t'installe un logiciel, puis il fait un ldd sur les binaires, va chercher les librairies non resolues, et eventuellement les installe.
rpm, ca doit ressembler pas mal a apt-get.
Que veux tu revoir dans cette facon de gerer les dependances?
Je suis un programmeur de la vieille école. Pour moi, soit on a des DLL ou l'équivalent chez linux (quelqu'un avait donné le terme, .so ?) qui sont des librairies dynamiques, soit le contenu des librairies est intégré au logiciel.
Si je regarde dans le Linux Debian que j'ai sur mon autre PC:
/bin contient un certain de fichiers exécutables qui me semblent autonomes: arch, bash, bzcat, etc. Des fichiers binaires ou des scripts.
/lib contient quelques .so, mais ils ne sont pas très nombreux et je ne vois pas où se cacheraient les librairies.
/etc contient d'autres fichiers exécutables. Tout comme /sbin ou /usr/bin
Il ne reste que les /usr/lib à contenir ce qui ressemble à des librairies dynamiques. Je suis peut-être un peu trop dans le monde MS pour le moment, mais il me semble que tous ces fichiers .so sont chacun trop petits pour que ce soit la même chose (en mieux, vu qu'ils ne sont pas tous au même endroit avec les problèmes que cela apporte quand 2 logiciels ont des DLL en conflit). Ou bien, est-ce que les dépendances ont pour seul but, quand il y a seulement des binaires, de télécharger les bons .so ?
Denis
Le Sun, 15 Jul 2007 19:47:48 +0000 (UTC), Kevin Denis
<kevin@nowhere.invalid> écrivait dans fr.comp.os.linux.debats:
Le 15-07-2007, Denis Beauregard a écrit :
Comme programmeur, je conçois facilement qu'on doive compiler
tels fichiers avec tel version d'une librairie ou une meilleure
version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux
ne compileront jamais rien sur leur ordinateur et iront seulement
chercher des logiciels déjà compilés ? De ce point de vue, ne
faudrait-il pas revoir la façon de gérer ces dépendances quand on
installe un nouveau logiciel pré-compilé ?
Bin... apt-get va chercher le logiciel qui te manque; avec ce
programme vient une liste de dependances nommees. apt-get verifie
recursivement si tout est la. S'il en manque, il va les chercher.
swaret t'installe un logiciel, puis il fait un ldd sur les binaires,
va chercher les librairies non resolues, et eventuellement les installe.
rpm, ca doit ressembler pas mal a apt-get.
Que veux tu revoir dans cette facon de gerer les dependances?
Je suis un programmeur de la vieille école. Pour moi, soit on a
des DLL ou l'équivalent chez linux (quelqu'un avait donné le
terme, .so ?) qui sont des librairies dynamiques, soit le contenu des
librairies est intégré au logiciel.
Si je regarde dans le Linux Debian que j'ai sur mon autre PC:
/bin contient un certain de fichiers exécutables qui me semblent
autonomes: arch, bash, bzcat, etc. Des fichiers binaires ou
des scripts.
/lib contient quelques .so, mais ils ne sont pas très nombreux
et je ne vois pas où se cacheraient les librairies.
/etc contient d'autres fichiers exécutables. Tout comme /sbin
ou /usr/bin
Il ne reste que les /usr/lib à contenir ce qui ressemble à des
librairies dynamiques. Je suis peut-être un peu trop dans le
monde MS pour le moment, mais il me semble que tous ces fichiers
.so sont chacun trop petits pour que ce soit la même chose (en
mieux, vu qu'ils ne sont pas tous au même endroit avec les
problèmes que cela apporte quand 2 logiciels ont des DLL en conflit).
Ou bien, est-ce que les dépendances ont pour seul but, quand il y a
seulement des binaires, de télécharger les bons .so ?
Le Sun, 15 Jul 2007 19:47:48 +0000 (UTC), Kevin Denis écrivait dans fr.comp.os.linux.debats:
Le 15-07-2007, Denis Beauregard a écrit :
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Bin... apt-get va chercher le logiciel qui te manque; avec ce
programme vient une liste de dependances nommees. apt-get verifie recursivement si tout est la. S'il en manque, il va les chercher.
swaret t'installe un logiciel, puis il fait un ldd sur les binaires, va chercher les librairies non resolues, et eventuellement les installe.
rpm, ca doit ressembler pas mal a apt-get.
Que veux tu revoir dans cette facon de gerer les dependances?
Je suis un programmeur de la vieille école. Pour moi, soit on a des DLL ou l'équivalent chez linux (quelqu'un avait donné le terme, .so ?) qui sont des librairies dynamiques, soit le contenu des librairies est intégré au logiciel.
Si je regarde dans le Linux Debian que j'ai sur mon autre PC:
/bin contient un certain de fichiers exécutables qui me semblent autonomes: arch, bash, bzcat, etc. Des fichiers binaires ou des scripts.
/lib contient quelques .so, mais ils ne sont pas très nombreux et je ne vois pas où se cacheraient les librairies.
/etc contient d'autres fichiers exécutables. Tout comme /sbin ou /usr/bin
Il ne reste que les /usr/lib à contenir ce qui ressemble à des librairies dynamiques. Je suis peut-être un peu trop dans le monde MS pour le moment, mais il me semble que tous ces fichiers .so sont chacun trop petits pour que ce soit la même chose (en mieux, vu qu'ils ne sont pas tous au même endroit avec les problèmes que cela apporte quand 2 logiciels ont des DLL en conflit). Ou bien, est-ce que les dépendances ont pour seul but, quand il y a seulement des binaires, de télécharger les bons .so ?
Denis
Emmanuel Florac
Le Sun, 15 Jul 2007 19:47:48 +0000, Kevin Denis a écrit :
rpm, ca doit ressembler pas mal a apt-get.
rpm ressemble plutôt à dpkg, il y a apt-rpm ou yum comme équivalents à apt-get. Apparemment yum est devenu le standard.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Sun, 15 Jul 2007 19:47:48 +0000, Kevin Denis a écrit :
rpm, ca doit ressembler pas mal a apt-get.
rpm ressemble plutôt à dpkg, il y a apt-rpm ou yum comme équivalents à
apt-get. Apparemment yum est devenu le standard.
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
Le Sun, 15 Jul 2007 19:47:48 +0000, Kevin Denis a écrit :
rpm, ca doit ressembler pas mal a apt-get.
rpm ressemble plutôt à dpkg, il y a apt-rpm ou yum comme équivalents à apt-get. Apparemment yum est devenu le standard.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Nicolas George
Denis Beauregard , dans le message , a écrit :
Je suis un programmeur de la vieille école. Pour moi, soit on a des DLL ou l'équivalent chez linux (quelqu'un avait donné le terme, .so ?) qui sont des librairies
En français, on dit bibliothèque.
dynamiques,
Le terme correct est partagé. Et même sous windows, ce ne sont pas des bibliothèques dynamiques, mais des bibliothèques à chargement dynamique, ce qui est assez différent.
soit le contenu des librairies est intégré au logiciel.
On appelle ça « lié statiquement ».
/bin contient un certain de fichiers exécutables qui me semblent autonomes: arch, bash, bzcat, etc. Des fichiers binaires ou des scripts.
Tu peux utiliser ldd sur un exécutable pour voir de quoi il dépend. Tu verras que bien peu de programmes dans /bin sont liés statiquement.
/lib contient quelques .so, mais ils ne sont pas très nombreux et je ne vois pas où se cacheraient les librairies.
.so veut dire shared object, ce sont précisément les bibliothèques. /lib contient les plus importantes : celles qui sont indispensables aux programmes assurant le boot, et la libc, qui sert à quasiment tous les programmes, puisqu'elle fait l'interface avec le noyau.
/etc contient d'autres fichiers exécutables.
Normalement, que des scripts.
Il ne reste que les /usr/lib à contenir ce qui ressemble à des librairies dynamiques.
Oui, c'est leur principal lieu de résidence.
Je suis peut-être un peu trop dans le monde MS pour le moment, mais il me semble que tous ces fichiers .so sont chacun trop petits pour que ce soit la même chose
Je ne vois pas ce qu'ils ont de trop petit. Il y en a un gros paquet qui dépassent le méga-octet, c'est considérable pour du code.
(en mieux, vu qu'ils ne sont pas tous au même endroit avec les problèmes que cela apporte quand 2 logiciels ont des DLL en conflit).
Les conflits de bibliothèques sont résolus par l'adjonction d'un numéro de version de l'ABI au nom du fichier, en général après le .so. Tu peux consulter le nom public d'un .so avec objdump -p, c'est le champ SONAME.
Ou bien, est-ce que les dépendances ont pour seul but, quand il y a seulement des binaires, de télécharger les bons .so ?
Exactement.
Denis Beauregard , dans le message
<3g1l93djb6qd4ldv20pd0fg20u0p4fk0ja@4ax.com>, a écrit :
Je suis un programmeur de la vieille école. Pour moi, soit on a
des DLL ou l'équivalent chez linux (quelqu'un avait donné le
terme, .so ?) qui sont des librairies
En français, on dit bibliothèque.
dynamiques,
Le terme correct est partagé. Et même sous windows, ce ne sont pas des
bibliothèques dynamiques, mais des bibliothèques à chargement dynamique, ce
qui est assez différent.
soit le contenu des
librairies est intégré au logiciel.
On appelle ça « lié statiquement ».
/bin contient un certain de fichiers exécutables qui me semblent
autonomes: arch, bash, bzcat, etc. Des fichiers binaires ou
des scripts.
Tu peux utiliser ldd sur un exécutable pour voir de quoi il dépend. Tu
verras que bien peu de programmes dans /bin sont liés statiquement.
/lib contient quelques .so, mais ils ne sont pas très nombreux
et je ne vois pas où se cacheraient les librairies.
.so veut dire shared object, ce sont précisément les bibliothèques. /lib
contient les plus importantes : celles qui sont indispensables aux
programmes assurant le boot, et la libc, qui sert à quasiment tous les
programmes, puisqu'elle fait l'interface avec le noyau.
/etc contient d'autres fichiers exécutables.
Normalement, que des scripts.
Il ne reste que les /usr/lib à contenir ce qui ressemble à des
librairies dynamiques.
Oui, c'est leur principal lieu de résidence.
Je suis peut-être un peu trop dans le
monde MS pour le moment, mais il me semble que tous ces fichiers
.so sont chacun trop petits pour que ce soit la même chose
Je ne vois pas ce qu'ils ont de trop petit. Il y en a un gros paquet qui
dépassent le méga-octet, c'est considérable pour du code.
(en
mieux, vu qu'ils ne sont pas tous au même endroit avec les
problèmes que cela apporte quand 2 logiciels ont des DLL en conflit).
Les conflits de bibliothèques sont résolus par l'adjonction d'un numéro de
version de l'ABI au nom du fichier, en général après le .so. Tu peux
consulter le nom public d'un .so avec objdump -p, c'est le champ SONAME.
Ou bien, est-ce que les dépendances ont pour seul but, quand il y a
seulement des binaires, de télécharger les bons .so ?
Je suis un programmeur de la vieille école. Pour moi, soit on a des DLL ou l'équivalent chez linux (quelqu'un avait donné le terme, .so ?) qui sont des librairies
En français, on dit bibliothèque.
dynamiques,
Le terme correct est partagé. Et même sous windows, ce ne sont pas des bibliothèques dynamiques, mais des bibliothèques à chargement dynamique, ce qui est assez différent.
soit le contenu des librairies est intégré au logiciel.
On appelle ça « lié statiquement ».
/bin contient un certain de fichiers exécutables qui me semblent autonomes: arch, bash, bzcat, etc. Des fichiers binaires ou des scripts.
Tu peux utiliser ldd sur un exécutable pour voir de quoi il dépend. Tu verras que bien peu de programmes dans /bin sont liés statiquement.
/lib contient quelques .so, mais ils ne sont pas très nombreux et je ne vois pas où se cacheraient les librairies.
.so veut dire shared object, ce sont précisément les bibliothèques. /lib contient les plus importantes : celles qui sont indispensables aux programmes assurant le boot, et la libc, qui sert à quasiment tous les programmes, puisqu'elle fait l'interface avec le noyau.
/etc contient d'autres fichiers exécutables.
Normalement, que des scripts.
Il ne reste que les /usr/lib à contenir ce qui ressemble à des librairies dynamiques.
Oui, c'est leur principal lieu de résidence.
Je suis peut-être un peu trop dans le monde MS pour le moment, mais il me semble que tous ces fichiers .so sont chacun trop petits pour que ce soit la même chose
Je ne vois pas ce qu'ils ont de trop petit. Il y en a un gros paquet qui dépassent le méga-octet, c'est considérable pour du code.
(en mieux, vu qu'ils ne sont pas tous au même endroit avec les problèmes que cela apporte quand 2 logiciels ont des DLL en conflit).
Les conflits de bibliothèques sont résolus par l'adjonction d'un numéro de version de l'ABI au nom du fichier, en général après le .so. Tu peux consulter le nom public d'un .so avec objdump -p, c'est le champ SONAME.
Ou bien, est-ce que les dépendances ont pour seul but, quand il y a seulement des binaires, de télécharger les bons .so ?
Exactement.
Denis Beauregard
Le Sun, 15 Jul 2007 14:30:49 -0400, Denis Beauregard écrivait dans fr.comp.os.linux.debats:
Bonjour,
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Merci à tous pour vos explications.
En ce qui concerne la grosseur des .so, en fait, j'ai regardé quelques répertoires seulement, ce qui explique que je n'ai pas vu les plus gros.
Denis
Le Sun, 15 Jul 2007 14:30:49 -0400, Denis Beauregard
<denis.b-at-francogene.com.invalid@nospam.com.invalid> écrivait dans
fr.comp.os.linux.debats:
Bonjour,
Comme programmeur, je conçois facilement qu'on doive compiler
tels fichiers avec tel version d'une librairie ou une meilleure
version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux
ne compileront jamais rien sur leur ordinateur et iront seulement
chercher des logiciels déjà compilés ? De ce point de vue, ne
faudrait-il pas revoir la façon de gérer ces dépendances quand on
installe un nouveau logiciel pré-compilé ?
Merci à tous pour vos explications.
En ce qui concerne la grosseur des .so, en fait, j'ai regardé
quelques répertoires seulement, ce qui explique que je n'ai pas
vu les plus gros.
Le Sun, 15 Jul 2007 14:30:49 -0400, Denis Beauregard écrivait dans fr.comp.os.linux.debats:
Bonjour,
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Merci à tous pour vos explications.
En ce qui concerne la grosseur des .so, en fait, j'ai regardé quelques répertoires seulement, ce qui explique que je n'ai pas vu les plus gros.
Denis
Michel Billaud
Denis Beauregard writes:
Bonjour,
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Les dépendances ne se limitent pas aux bibliothèques.
Imaginons qu'on veuille installer "mutt", pour lire-envoyer du courrier (mail user agent) Il ne serait pas raisonnable de l'installer sans disposer d'un agent de transport de courrier. D'où dépendance.
Il existe une tripotée de tels MTA : courier, esmtp, exim postfix, sendmail, smail, ssmtp, etc. Ce ne sont pas que des bibliothèques, mais des logiciels à part entière, avec leurs outils de configuration etc. Certains de ces outils nécessitent d'autres outils etc.
D'ou l'interêt, pour s'y retrouver, du système de dépendances qui indique, pour chaque paquet, de quoi il dépend, avec quoi il est en conflit, les paquets qui sont recommandés ou conseillés etc.
Ca éviterait, par exemple sur une slackware, de ne pas pouvoir lire les pages de manuel alors que les packages man et pages sont bien là. Ah oui, il faut aussi groff, comme on peut le deviner.
Voila un bout des informations à propos de mutt chez moi
Paquet source : mutt -- Dépend --- exim4 | mail-transport-agent --- libc6 (>= 2.3.6-6) --- libdb4.4 --- libgnutls13 (>= 1.4.0-0) --- libidn11 (>= 0.5.18) --- libncursesw5 (>= 5.4-5) --- libsasl2-2 -- Suggère --- aspell | ispell --- ca-certificates --- gnupg --- mixmaster (NON SATISFAITE) --- openssl --- urlview (NON SATISFAITE) -- Recommande --- locales --- mime-support -- Est en conflit avec --- mutt-utf8 -- Remplace --- mutt-utf8 -- Noms de paquet fournis par mutt v imap-client O v mail-reader etc.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Comme programmeur, je conçois facilement qu'on doive compiler
tels fichiers avec tel version d'une librairie ou une meilleure
version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux
ne compileront jamais rien sur leur ordinateur et iront seulement
chercher des logiciels déjà compilés ? De ce point de vue, ne
faudrait-il pas revoir la façon de gérer ces dépendances quand on
installe un nouveau logiciel pré-compilé ?
Les dépendances ne se limitent pas aux bibliothèques.
Imaginons qu'on veuille installer "mutt", pour lire-envoyer du
courrier (mail user agent) Il ne serait pas raisonnable de l'installer
sans disposer d'un agent de transport de courrier. D'où dépendance.
Il existe une tripotée de tels MTA : courier, esmtp, exim postfix,
sendmail, smail, ssmtp, etc. Ce ne sont pas que des bibliothèques,
mais des logiciels à part entière, avec leurs outils de configuration
etc. Certains de ces outils nécessitent d'autres outils etc.
D'ou l'interêt, pour s'y retrouver, du système de dépendances qui
indique, pour chaque paquet, de quoi il dépend, avec quoi il est en
conflit, les paquets qui sont recommandés ou conseillés etc.
Ca éviterait, par exemple sur une slackware, de ne pas pouvoir lire
les pages de manuel alors que les packages man et pages sont bien
là. Ah oui, il faut aussi groff, comme on peut le deviner.
Voila un bout des informations à propos de mutt chez moi
Paquet source : mutt
-- Dépend
--- exim4 | mail-transport-agent
--- libc6 (>= 2.3.6-6)
--- libdb4.4
--- libgnutls13 (>= 1.4.0-0)
--- libidn11 (>= 0.5.18)
--- libncursesw5 (>= 5.4-5)
--- libsasl2-2
-- Suggère
--- aspell | ispell
--- ca-certificates
--- gnupg
--- mixmaster (NON SATISFAITE)
--- openssl
--- urlview (NON SATISFAITE)
-- Recommande
--- locales
--- mime-support
-- Est en conflit avec
--- mutt-utf8
-- Remplace
--- mutt-utf8
-- Noms de paquet fournis par mutt
v imap-client O
v mail-reader
etc.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Comme programmeur, je conçois facilement qu'on doive compiler tels fichiers avec tel version d'une librairie ou une meilleure version. Je comprends donc à quoi servent les dépendances.
Mais ne peut-on pas dire qu'une majorité d'utilisateurs de Linux ne compileront jamais rien sur leur ordinateur et iront seulement chercher des logiciels déjà compilés ? De ce point de vue, ne faudrait-il pas revoir la façon de gérer ces dépendances quand on installe un nouveau logiciel pré-compilé ?
Les dépendances ne se limitent pas aux bibliothèques.
Imaginons qu'on veuille installer "mutt", pour lire-envoyer du courrier (mail user agent) Il ne serait pas raisonnable de l'installer sans disposer d'un agent de transport de courrier. D'où dépendance.
Il existe une tripotée de tels MTA : courier, esmtp, exim postfix, sendmail, smail, ssmtp, etc. Ce ne sont pas que des bibliothèques, mais des logiciels à part entière, avec leurs outils de configuration etc. Certains de ces outils nécessitent d'autres outils etc.
D'ou l'interêt, pour s'y retrouver, du système de dépendances qui indique, pour chaque paquet, de quoi il dépend, avec quoi il est en conflit, les paquets qui sont recommandés ou conseillés etc.
Ca éviterait, par exemple sur une slackware, de ne pas pouvoir lire les pages de manuel alors que les packages man et pages sont bien là. Ah oui, il faut aussi groff, comme on peut le deviner.
Voila un bout des informations à propos de mutt chez moi
Paquet source : mutt -- Dépend --- exim4 | mail-transport-agent --- libc6 (>= 2.3.6-6) --- libdb4.4 --- libgnutls13 (>= 1.4.0-0) --- libidn11 (>= 0.5.18) --- libncursesw5 (>= 5.4-5) --- libsasl2-2 -- Suggère --- aspell | ispell --- ca-certificates --- gnupg --- mixmaster (NON SATISFAITE) --- openssl --- urlview (NON SATISFAITE) -- Recommande --- locales --- mime-support -- Est en conflit avec --- mutt-utf8 -- Remplace --- mutt-utf8 -- Noms de paquet fournis par mutt v imap-client O v mail-reader etc.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Denis Beauregard
Le 24 Jul 2007 15:13:06 +0200, Michel Billaud écrivait dans fr.comp.os.linux.debats:
Les dépendances ne se limitent pas aux bibliothèques.
Imaginons qu'on veuille installer "mutt", pour lire-envoyer du courrier (mail user agent) Il ne serait pas raisonnable de l'installer sans disposer d'un agent de transport de courrier. D'où dépendance.
Il existe une tripotée de tels MTA : courier, esmtp, exim postfix, sendmail, smail, ssmtp, etc. Ce ne sont pas que des bibliothèques, mais des logiciels à part entière, avec leurs outils de configuration etc. Certains de ces outils nécessitent d'autres outils etc.
D'ou l'interêt, pour s'y retrouver, du système de dépendances qui indique, pour chaque paquet, de quoi il dépend, avec quoi il est en conflit, les paquets qui sont recommandés ou conseillés etc.
J'ai l'impression alors que Debian est mal configuré.
Quand j'ai voulu installer une imprimante, j'ai appris par la suite qu'il manquait 3 ou 4 autres éléments. Par exemple, il me fallait cups ou un équivalent. Il a alors fallu que je recherche ce qui manquait. Cela fait un bon moment, alors je ne sais pas si cela a changé ou pas.
En tous cas, c'est effectivement une bonne utilisation des dépendances.
Denis
Le 24 Jul 2007 15:13:06 +0200, Michel Billaud
<billaud@serveur5.labri.fr> écrivait dans fr.comp.os.linux.debats:
Les dépendances ne se limitent pas aux bibliothèques.
Imaginons qu'on veuille installer "mutt", pour lire-envoyer du
courrier (mail user agent) Il ne serait pas raisonnable de l'installer
sans disposer d'un agent de transport de courrier. D'où dépendance.
Il existe une tripotée de tels MTA : courier, esmtp, exim postfix,
sendmail, smail, ssmtp, etc. Ce ne sont pas que des bibliothèques,
mais des logiciels à part entière, avec leurs outils de configuration
etc. Certains de ces outils nécessitent d'autres outils etc.
D'ou l'interêt, pour s'y retrouver, du système de dépendances qui
indique, pour chaque paquet, de quoi il dépend, avec quoi il est en
conflit, les paquets qui sont recommandés ou conseillés etc.
J'ai l'impression alors que Debian est mal configuré.
Quand j'ai voulu installer une imprimante, j'ai appris par la
suite qu'il manquait 3 ou 4 autres éléments. Par exemple, il me
fallait cups ou un équivalent. Il a alors fallu que je recherche
ce qui manquait. Cela fait un bon moment, alors je ne sais pas si
cela a changé ou pas.
En tous cas, c'est effectivement une bonne utilisation des
dépendances.
Le 24 Jul 2007 15:13:06 +0200, Michel Billaud écrivait dans fr.comp.os.linux.debats:
Les dépendances ne se limitent pas aux bibliothèques.
Imaginons qu'on veuille installer "mutt", pour lire-envoyer du courrier (mail user agent) Il ne serait pas raisonnable de l'installer sans disposer d'un agent de transport de courrier. D'où dépendance.
Il existe une tripotée de tels MTA : courier, esmtp, exim postfix, sendmail, smail, ssmtp, etc. Ce ne sont pas que des bibliothèques, mais des logiciels à part entière, avec leurs outils de configuration etc. Certains de ces outils nécessitent d'autres outils etc.
D'ou l'interêt, pour s'y retrouver, du système de dépendances qui indique, pour chaque paquet, de quoi il dépend, avec quoi il est en conflit, les paquets qui sont recommandés ou conseillés etc.
J'ai l'impression alors que Debian est mal configuré.
Quand j'ai voulu installer une imprimante, j'ai appris par la suite qu'il manquait 3 ou 4 autres éléments. Par exemple, il me fallait cups ou un équivalent. Il a alors fallu que je recherche ce qui manquait. Cela fait un bon moment, alors je ne sais pas si cela a changé ou pas.
En tous cas, c'est effectivement une bonne utilisation des dépendances.