Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Et pourquoi ces dépendances ?

7 réponses
Avatar
Denis Beauregard
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é ?


Denis

7 réponses

Avatar
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

Avatar
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


Avatar
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.

Avatar
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.

Avatar
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

Avatar
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)

Avatar
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