Gestion des dépendances

Le
JEf
Bonjour,

J'aimerais avoir votre avis sur la gestion des dépendances de MacOS
comparée à celle de linux.

Sous Mac (en applications natives), il n'y a pas de dépendances, toutes
les librairies nécessaires à l'appli sont dans le folder .app de
l'application.

Sous linux, il y a une gestion complexe des dépendances.

Donc sur Mac pour installer une appli on la copie sur son disque dur et
on lui donne les autorisations d'exécution (la demande de mot de passe à
l'install dans le dossier /Applications).

Sous Linux vous savez comment cela fonctionne.

Un exemple ou cela serait utile :
- Ubuntu server 9.10
- python 2.6 (version installée par défaut)
- apt-get fail2ban

On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.

Donc il faut faire en plus
- apt-get install python2.5
- modifier les fichiers de fail2ban pour utiliser cette version

Ce ne serait pas arrivé sur Mac.

Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?

TIA,

JEf
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #22452461
JEf wrote in message
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.



Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet.
L'as-tu fait ?

Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?



On a la passion de faire les choses bien ou on ne l'a pas.
JEf
Le #22452521
On 08/08/10 10:59, Nicolas George wrote:
JEf wrote in message
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.



Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet.
L'as-tu fait ?

Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?



On a la passion de faire les choses bien ou on ne l'a pas.



C'est indiqué dans les faq de fail2ban, c'est un prob connu (sous 9.04
et 9.10)

Un exemple
http://www.howtoforge.com/forums/showthread.php?t4886

Pour répondre à la question, oui j'ai indiqué le prob chez ubuntu.

HTH

JEf
JKB
Le #22452651
Le 08 Aug 2010 08:59:48 GMT,
Nicolas George
JEf wrote in message
On démarre fail2ban, ça fonctionne pas. La dépendance est python 2.5. La
2.6 étant installée, pas de prob pour le gestionnaire de paquet par
contre fail2ban ne fonctionne pas bien.



Ce n'est pas normal, il faudrait signaler ça aux mainteneurs du paquet.
L'as-tu fait ?

Alors oui cela consommera plus de disque à la mac qu'à la linux. Et plus
de ram. Mais au prix de la ram et des disques, est-ce vraiment un problème ?



On a la passion de faire les choses bien ou on ne l'a pas.



Ça dépend. Il y a des cas où tu ne peux pas te permettre de faire
autre chose que de lier un soft en statique (ce qui revient au même
que de coller les bibliothèques partagées dans un répertoire
spécifique à l'application). Lorsque tu restes dans un environnement
Linux, tu peux souvent faire autrement, mais lorsque tu écris un
soft un peu gros et réellement portable, c'est beaucoup plus
difficile. Il est quasiment impossible de trouver directement la
bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible
et généralement, lesdites bibliothèques ne se compilent pas out of
the box. Tu vas me dire que c'est parce qu'elles sont écrites avec
des pieds et tu auras raison. Le problème n'est pa de savoir si
elles sont bien ou mal écrites mais si elles sont disponibles
facilement sur l'OS cible.

Si tu veux un exemple marrant, regarde file-5.03 et essaye
simplement de compiler la chose sous Linux/sparc, NetBSD/alpha ou
openVMS/Itanium puis de l'utiliser. Sur toutes les architecture à
alignement mémoire, ça merdoie allègrement. Regarde aussi ncurses
sous Solaris (qui est liée par défaut à -lform pour sa version statique,
lequel lform provient de curses livré par Sun et non de ncurses.
Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).
Bref, dans la vraie vie, il est idiot de dire que quelqu'un qui embarque
dans un logiciel ce qu'il faut pour qu'il tourne correctement ne fait pas
les choses bien.

Un autre exemple qui m'emmerde actuellement : j'ai une application
qui utilise à la fois la libpq du système (debian stable) et openssl
1.0.0. Regarde le résultat pour t'amuser et ce qu'il faut faire pour
contourner le problème. Ça termine par des recompilations de
postgres et un grand coup de LD_PRELOAD ou d'édition des liens
statiques.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Tonton Th
Le #22453491
On 08/08/2010 10:55 AM, JEf wrote:

Sous linux, il y a une gestion complexe des dépendances.




En fait, non, pas du tout, efface :)

Linux, ce n'est que le noyau, le kerne, la quenelle, le
moteur interne du système. Ensuite, là-dessus, il y a
les bibliothèques de fonctions de base, sur lesquelles
sont construites d'autre bibliothèques plus "avancées",
par exemple ce qui permet de lire une image encodée en
TIFF, en encore là-dessus les applications, genre le soft
qui te permet de regarder une image tiff.

C'est l'assemblage de tout ces morceaux de logiciels
que l'on appelle une "distribution Linux", et chacune
de ces distributions gère les dépendances entre les
diverses briques logicielles à sa façon.

Je ne pratique que deux de ces distributions : Debian
(et ses dérivées) et Slackware. La première a un truc
magique extrèmement puissant pour gérer l'arbre/le graphe
des dépendances entre les couches de briques, les applis,
les trucs et les machins. La seconde considère que celui
qui tape sur le clavier peut lui-même gérer ces dépendances
et ne s'en préoccupe donc absolument pas.

Pour moi, ces deux façons de faire, placées chacune à une
des deux extrèmités de l'axe des façons d'appréhender la
gestion des dépendances, sont aussi positives l'une que
l'autre. Par contre, il y a des compromis entre ces deux
points pivots, qui, euh...

Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.



--
Et pendant ce temps-là, dans le golfe du Mexique...
Patrick Lamaizière
Le #22456001
JKB :

Un autre exemple qui m'emmerde actuellement : j'ai une application



...

Et Libtool ça n'aide pas ? (c't une vraie question).
JEf
Le #22456131
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.



Pourquoi ? Sur un serveur où on recherche des gains de performance je ne
dis pas (et encore quand je vois le gaspi de la mode du cloud et autres
systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?

JEf
JKB
Le #22457111
Le Mon, 09 Aug 2010 21:27:39 +0200,
Patrick Lamaizière
JKB :

Un autre exemple qui m'emmerde actuellement : j'ai une application



...

Et Libtool ça n'aide pas ? (c't une vraie question).



Pas vraiment. Libtool est buggué jusqu'à la moëlle et rempli de
gnueries même pas compatibles avec les outils GNU. Là, je bataille
avec la compilation de GSL 1.14 sous eCS. J'ai installé tous les
outils GNU et je suis obligé de triturer le ltmain.sh à grands coups
de sed pour obtenir après _deux_ passage de configure quelque chose
de potable. Libtool, ça n'a été écrit que pour du GNU en emmerdant
prodigieusement tout ce qui n'est pas GNU ou qui est GNU mais un peu
ancien.

Regarde juste un peu les joyeusetés comme ${1 + "$@"} dans un shell
plus vieux qu'un bash 4.x (par exemple un bash 3.2 livré par défaut
avec eCS)

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Tonton Th
Le #22457231
On 08/09/2010 10:15 PM, JEf wrote:
On 08/08/10 22:24, Tonton Th wrote:
Quand à tirer les libs dans le répertoire de l'application,
c'est quand même un truc de merde. Amha.



systèmes de machines virtuelles). Mais sur un desktop grand public où le
but est que toute appli doit fonctionner peu importe les autres softs
installés ?



C'est toujours un truc de merde.

--
Et pendant ce temps-là, dans le golfe du Mexique...
Nicolas George
Le #22457271
JKB wrote in message
Il est quasiment impossible de trouver directement la
bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible



Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de
choisir les bons -I et -L pour avoir des versions cohérentes des
bibliothèques, ce n'est pas le problème du développeur, c'est le problème de
celui qui cherche à compiler un paquet sur un système incohérent.

Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).



Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me
surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas
un principe.

Un autre exemple qui m'emmerde actuellement : j'ai une application
qui utilise à la fois la libpq du système (debian stable) et openssl
1.0.0. Regarde le résultat pour t'amuser



Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise
openssl du système, la libpq du système sera compilée avec et tu n'auras pas
de soucis.
JKB
Le #22457291
Le 10 Aug 2010 08:39:41 GMT,
Nicolas George
JKB wrote in message
Il est quasiment impossible de trouver directement la
bonne bibliothèque (au hasard ncurses ou gsl) sur le système cible



Je ne comprends pas ce que tu veux dire par « trouver ». S'il s'agit de
choisir les bons -I et -L pour avoir des versions cohérentes des
bibliothèques, ce n'est pas le problème du développeur, c'est le problème de
celui qui cherche à compiler un paquet sur un système incohérent.



C'est très facile. Sous Solaris, par exemple, tu n'as pas ncurses,
mais un curses fourni par Sun^Oracle qui est subtilement
incompatible avec ncurses. Tu dois donc recompiler ncurses, et là,
tu as intérêt de lier statiquement le ncurses à ton exécutable sous
peine de voir des choses amusantes dans les utilitaires du système
ou de coller la libncurses.so dans un répertoire spécifique à ton
application et demander à tes utilisateurs de lancer ton application
avec un LD_PRELOAD. Il n'y a pas que Linux dans la vie.

Après plusieurs bugs reports, ils ont _enfin_ accepté mes patches !).



Un bug ponctuel, même si les développeurs traînent à le corriger (ce qui me
surprend, THomas Dickey m'ayant toujours semblé très réactif) n'invalide pas
un principe.



Ponctuel ? Ça m'a juste pris deux ans parce que mes architectures
cibles n'étaient pas vraiment une priorité.

Un autre exemple qui m'emmerde actuellement : j'ai une application
qui utilise à la fois la libpq du système (debian stable) et openssl
1.0.0. Regarde le résultat pour t'amuser



Ben c'est ta faute, tu mélanges les choses, tu cherches les ennuis. Utilise
openssl du système, la libpq du système sera compilée avec et tu n'auras pas
de soucis.



Et lorsqu'il te _faut_ openssl 1.0.0 ? Tu réponds aussi 'tu n'as
qu'à utiliser 0.9.8x ' ?

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
=> http://grincheux.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme