Un débat intéressant et sans doute récurant que l'on voit apparaître
régulièrement sur les forums, et relatif quant au choix de la
distribution...
Linux pour quoi faire ? Tout d'abord clarifions la chose pour dire que
"linux" est le nom du kernel et non du system d'exploitation lui-même...
Petite précision pour les débutants linux. Il faut alors parler de
distribution GNU Linux...
Donc qu'attendez-vous d'un OS libre (par opposition à Windows) ?
Nous savons que Linux est une bonne solution s'il on veut faire un réseau ;
aussi peut-il est aussi une solution en terme de bureautique pure (Office) ?
La partie jeu reste une ombre pour ma part... peut-il concurrencer les
jeux sous Windows ?
Le choix de la distrib reste aussi, difficile dans la perspective des
mises à jour ? Je pense que c'est la que réside la difficulté. RPMS,
PKG, DEB, Yum, ou encore version type gentoo... , installation depuis les
sources, etc. Facilité, Rapidité ou encore prise de caféine, tels sont
les choix qui sont offerts. Un point important réside aussi dans la
sécurité...
Ayant tester une multitude de distrib (redhat, fedora, gentoo, mdk7.0 !,
archlinux, freebsd, solaris, etc), je ne sais sur quoi me baser afin de
trouver un bon compromis. L'on pourra consulter un site tel que
http://www.distrowatch.com afin d'y trouver un bref exposer des distribs
linux, avec les différents liens qui s'y rattachent.
Vos commentaires, et autres suggestions pour extrapoler ces propos seront
les bienvenus afin de clarifier certaines idées...
Amha une seule distrib me semble ignorer ces problemes, c'est la Debian, pour la simple raison que (presque) tous les paquetages sont prévus dès le départ...
C'est vrai si tu parles de la unstable, mais si tu parles de la stable, laisse moi rire. Je n'ai jamais autant compilé que depuis que j'ai une Debian stable, et je ne parle pas de la prise de tête que c'est de faire des paquets .deb pour faire rentrer tout ça dans le moule.
Amha une seule distrib me semble ignorer ces problemes, c'est la Debian,
pour la simple raison que (presque) tous les paquetages sont prévus dès
le départ...
C'est vrai si tu parles de la unstable, mais si tu parles de la stable,
laisse moi rire. Je n'ai jamais autant compilé que depuis que j'ai une
Debian stable, et je ne parle pas de la prise de tête que c'est de faire
des paquets .deb pour faire rentrer tout ça dans le moule.
Amha une seule distrib me semble ignorer ces problemes, c'est la Debian, pour la simple raison que (presque) tous les paquetages sont prévus dès le départ...
C'est vrai si tu parles de la unstable, mais si tu parles de la stable, laisse moi rire. Je n'ai jamais autant compilé que depuis que j'ai une Debian stable, et je ne parle pas de la prise de tête que c'est de faire des paquets .deb pour faire rentrer tout ça dans le moule.
--
Michel TALON
Manuel Leclerc
avec des jeux futés sur le vfs. Une fois qu'on a compris (ce qui ne semble pas être encore bien rentré dans toutes les têtes) que l'espace disque est un non problème, il y a beaucoup d'options.
Ton histoire de "vfs", c'est pour la mémoire, qui n'est pas un non problème, elle ?
Reste aussi à intégrer les correctifs d'un composants partagés.
--
http://www.linuxdevices.com/files/misc/asay-paper.pdf My method of accessing the web through email and wget does not
work for binary files, so I don't know what is in that file. --Richard Stallman
avec des jeux futés sur le vfs. Une fois qu'on a compris
(ce qui ne semble pas être encore bien rentré dans toutes
les têtes) que l'espace disque est un non problème, il y
a beaucoup d'options.
Ton histoire de "vfs", c'est pour la mémoire, qui n'est pas
un non problème, elle ?
Reste aussi à intégrer les correctifs d'un composants
partagés.
--
http://www.linuxdevices.com/files/misc/asay-paper.pdf
My method of accessing the web through email and wget does not
work for binary files, so I don't know what is in that file.
--Richard Stallman
avec des jeux futés sur le vfs. Une fois qu'on a compris (ce qui ne semble pas être encore bien rentré dans toutes les têtes) que l'espace disque est un non problème, il y a beaucoup d'options.
Ton histoire de "vfs", c'est pour la mémoire, qui n'est pas un non problème, elle ?
Reste aussi à intégrer les correctifs d'un composants partagés.
--
http://www.linuxdevices.com/files/misc/asay-paper.pdf My method of accessing the web through email and wget does not
work for binary files, so I don't know what is in that file. --Richard Stallman
george
Michel Talon, dans le message <c5326u$21k7$, a écrit :
Pourquoi? Toi qui es un si grand partisan du découpage, qu'est-ce que ça peut bien te faire qu'on ait mis des fonctions spécifiques réentrantes dans une librairie séparée au lieu de les mettre en vrac dans la libc?
Tu te trompes : la libc_r dont je parlais fait double emploi avec la libc tout court.
Trop fort : tu essaies sur un programme qui n'a pas le problème, et oh surprise, il n'a pas le problème !
Je n'ai pas d'exemple sous la main, parce qu'on a fait du ménage, mais je n'invente pas. Une bibal A non threadée compilée avec libc.so.4, un programme P threadé qui utilise A, et déjà deux libc. Ajoutons que P dépend de B, qu'on a recompilé après le passage à libc.so.5, et on a une troisième libc pour faire chier le monde.
C'est surtout que le dynamic loader de versions récentes est incompatible avec des libc trop vieilles, et que donc tu l'as dans l'os complètement. Une chose qui ne s'est jamais produite avec FreeBSD où tu peux faire tourner sur les versions les plus récentes des programmes datant du tout début de FreeBSD, à condition bien sûr d'avoir gardé les libc correspondantes (mais elles existent en port).
Sauf que quand le dynamic loader change, son nom change également. Et depuis pas mal de temps, la libc ne doit plus du tout changer, avec le symbol versionning. Alors que les problèmes de libc différentes sous BSD, c'est encore d'actualité.
Bien sûr, tu viens pinailler sur de l'espace disque dont personne n'a rien à faire et qu'au mieux tu vas remplir de porn,
Garde tes attaques gratuites pour toi, merci.
si jamais il y a un jour quelque chose dessus,
Le découpage des packages ne coûte strictement rien et permet d'économiser de la place. Les « performances » de BSD, c'est au coût d'un OS complètement merdique. Ma priorité va toujours à ce qui marche. De fait, BSD ne marche pas.
Michel Talon, dans le message <c5326u$21k7$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Pourquoi? Toi qui es un si grand partisan du découpage, qu'est-ce que ça
peut bien te faire qu'on ait mis des fonctions spécifiques réentrantes
dans une librairie séparée au lieu de les mettre en vrac dans la libc?
Tu te trompes : la libc_r dont je parlais fait double emploi avec la
libc tout court.
Trop fort : tu essaies sur un programme qui n'a pas le problème, et oh
surprise, il n'a pas le problème !
Je n'ai pas d'exemple sous la main, parce qu'on a fait du ménage, mais
je n'invente pas. Une bibal A non threadée compilée avec libc.so.4, un
programme P threadé qui utilise A, et déjà deux libc. Ajoutons que P
dépend de B, qu'on a recompilé après le passage à libc.so.5, et on a une
troisième libc pour faire chier le monde.
C'est surtout que le dynamic loader de versions récentes est
incompatible avec des libc trop vieilles, et que donc tu l'as dans l'os
complètement. Une chose qui ne s'est jamais produite avec FreeBSD où tu
peux faire tourner sur les versions les plus récentes des programmes
datant du tout début de FreeBSD, à condition bien sûr d'avoir gardé les
libc correspondantes (mais elles existent en port).
Sauf que quand le dynamic loader change, son nom change également. Et
depuis pas mal de temps, la libc ne doit plus du tout changer, avec le
symbol versionning. Alors que les problèmes de libc différentes sous
BSD, c'est encore d'actualité.
Bien sûr, tu viens pinailler sur de l'espace disque dont personne n'a
rien à faire et qu'au mieux tu vas remplir de porn,
Garde tes attaques gratuites pour toi, merci.
si jamais il y a un
jour quelque chose dessus,
Le découpage des packages ne coûte strictement rien et permet
d'économiser de la place. Les « performances » de BSD, c'est au coût
d'un OS complètement merdique. Ma priorité va toujours à ce qui marche.
De fait, BSD ne marche pas.
Michel Talon, dans le message <c5326u$21k7$, a écrit :
Pourquoi? Toi qui es un si grand partisan du découpage, qu'est-ce que ça peut bien te faire qu'on ait mis des fonctions spécifiques réentrantes dans une librairie séparée au lieu de les mettre en vrac dans la libc?
Tu te trompes : la libc_r dont je parlais fait double emploi avec la libc tout court.
Trop fort : tu essaies sur un programme qui n'a pas le problème, et oh surprise, il n'a pas le problème !
Je n'ai pas d'exemple sous la main, parce qu'on a fait du ménage, mais je n'invente pas. Une bibal A non threadée compilée avec libc.so.4, un programme P threadé qui utilise A, et déjà deux libc. Ajoutons que P dépend de B, qu'on a recompilé après le passage à libc.so.5, et on a une troisième libc pour faire chier le monde.
C'est surtout que le dynamic loader de versions récentes est incompatible avec des libc trop vieilles, et que donc tu l'as dans l'os complètement. Une chose qui ne s'est jamais produite avec FreeBSD où tu peux faire tourner sur les versions les plus récentes des programmes datant du tout début de FreeBSD, à condition bien sûr d'avoir gardé les libc correspondantes (mais elles existent en port).
Sauf que quand le dynamic loader change, son nom change également. Et depuis pas mal de temps, la libc ne doit plus du tout changer, avec le symbol versionning. Alors que les problèmes de libc différentes sous BSD, c'est encore d'actualité.
Bien sûr, tu viens pinailler sur de l'espace disque dont personne n'a rien à faire et qu'au mieux tu vas remplir de porn,
Garde tes attaques gratuites pour toi, merci.
si jamais il y a un jour quelque chose dessus,
Le découpage des packages ne coûte strictement rien et permet d'économiser de la place. Les « performances » de BSD, c'est au coût d'un OS complètement merdique. Ma priorité va toujours à ce qui marche. De fait, BSD ne marche pas.
george
Jerome Lambert , dans le message , a écrit :
Il pointe vers les fichiers qui lui ont servi lors de l'install. Ca me parait coherent comme configuration, non?
Non, c'est stupide, le mode a changé, depuis.
D'accord, mais j'ai l'impression qu'une distribution est un ensemble de paquets coherents à une date d pour des versions v des programmes.
Mauvaise impression, changer d'impression. Une distribution, c'est normalement un ensemble cohérent de paquets à tout instant
Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n à version n+1, mais à ce rythme-là on rentre dans des procédés Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver à "comme la machine se traine, il faut en changer".
Dis, tu lis et comprends ce que j'écris, ou ton cerveau est déjà en vacances ? Si tu veux installer le programme foo, et qu'il a besoin de la libbar version 42 ou plus, alors que tu n'as que la version 41, tu _dois_ installer une libbar 42, tu n'as pas le choix.
Jerome Lambert , dans le message
<pan.2004.04.08.09.25.37.262787@swing.aretirer.be>, a écrit :
Il pointe vers les fichiers qui lui ont servi lors de l'install. Ca me
parait coherent comme configuration, non?
Non, c'est stupide, le mode a changé, depuis.
D'accord, mais j'ai l'impression qu'une distribution est un ensemble de
paquets coherents à une date d pour des versions v des programmes.
Mauvaise impression, changer d'impression. Une distribution, c'est
normalement un ensemble cohérent de paquets à tout instant
Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n
à version n+1, mais à ce rythme-là on rentre dans des procédés
Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver
à "comme la machine se traine, il faut en changer".
Dis, tu lis et comprends ce que j'écris, ou ton cerveau est déjà en
vacances ? Si tu veux installer le programme foo, et qu'il a besoin de
la libbar version 42 ou plus, alors que tu n'as que la version 41, tu
_dois_ installer une libbar 42, tu n'as pas le choix.
Il pointe vers les fichiers qui lui ont servi lors de l'install. Ca me parait coherent comme configuration, non?
Non, c'est stupide, le mode a changé, depuis.
D'accord, mais j'ai l'impression qu'une distribution est un ensemble de paquets coherents à une date d pour des versions v des programmes.
Mauvaise impression, changer d'impression. Une distribution, c'est normalement un ensemble cohérent de paquets à tout instant
Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n à version n+1, mais à ce rythme-là on rentre dans des procédés Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver à "comme la machine se traine, il faut en changer".
Dis, tu lis et comprends ce que j'écris, ou ton cerveau est déjà en vacances ? Si tu veux installer le programme foo, et qu'il a besoin de la libbar version 42 ou plus, alors que tu n'as que la version 41, tu _dois_ installer une libbar 42, tu n'as pas le choix.
talon
Manuel Leclerc wrote:
avec des jeux futés sur le vfs. Une fois qu'on a compris (ce qui ne semble pas être encore bien rentré dans toutes les têtes) que l'espace disque est un non problème, il y a beaucoup d'options.
Ton histoire de "vfs", c'est pour la mémoire, qui n'est pas un non problème, elle ?
Non mon histoire de vfs c'est de jouer sur le virtual filesystem pour présenter aux programmes une vision du filesystem adaptée à chaque programme. Par exemple on peut imaginer que tel programme voit une libc différente de celle que voit un autre programme, bien qu'elles s'appellent pareil ..., histoire de faire râler certain linuxien. Pour le moment une petite partie seulement de ces mécanismes a été implémentée dans dragonflybsd, les "variant symlinks", qui consistent en liens symboliques (ln -s toto tata) dont l'interprétation dépend du positionnement d'une variable d'environnement. Tu peux alors imaginer d'avoir des symlinks à variantes dans /usr/lib qui pointent sur des librairies différentes selon la manière dont on a positionné la variable d'environnement dans le script qui lance le programme. Mais tu peux faire pire. Tu peux imaginer un système de ports où quand on compile un paquet, tout y compris le choix du compilateur soit susceptible de variation par ce mécanisme.
Reste aussi à intégrer les correctifs d'un composants partagés.
--
Michel TALON
Manuel Leclerc <manuel.leclerc@alussinan.org> wrote:
avec des jeux futés sur le vfs. Une fois qu'on a compris
(ce qui ne semble pas être encore bien rentré dans toutes
les têtes) que l'espace disque est un non problème, il y
a beaucoup d'options.
Ton histoire de "vfs", c'est pour la mémoire, qui n'est pas
un non problème, elle ?
Non mon histoire de vfs c'est de jouer sur le virtual filesystem
pour présenter aux programmes une vision du filesystem adaptée à chaque
programme. Par exemple on peut imaginer que tel programme voit une
libc différente de celle que voit un autre programme, bien qu'elles
s'appellent pareil ..., histoire de faire râler certain linuxien.
Pour le moment une petite partie seulement de ces mécanismes a été
implémentée dans dragonflybsd, les "variant symlinks", qui consistent
en liens symboliques (ln -s toto tata) dont l'interprétation dépend
du positionnement d'une variable d'environnement. Tu peux alors imaginer
d'avoir des symlinks à variantes dans /usr/lib qui pointent sur des
librairies différentes selon la manière dont on a positionné la variable
d'environnement dans le script qui lance le programme. Mais tu peux
faire pire. Tu peux imaginer un système de ports où quand on compile
un paquet, tout y compris le choix du compilateur soit susceptible de
variation par ce mécanisme.
Reste aussi à intégrer les correctifs d'un composants
partagés.
avec des jeux futés sur le vfs. Une fois qu'on a compris (ce qui ne semble pas être encore bien rentré dans toutes les têtes) que l'espace disque est un non problème, il y a beaucoup d'options.
Ton histoire de "vfs", c'est pour la mémoire, qui n'est pas un non problème, elle ?
Non mon histoire de vfs c'est de jouer sur le virtual filesystem pour présenter aux programmes une vision du filesystem adaptée à chaque programme. Par exemple on peut imaginer que tel programme voit une libc différente de celle que voit un autre programme, bien qu'elles s'appellent pareil ..., histoire de faire râler certain linuxien. Pour le moment une petite partie seulement de ces mécanismes a été implémentée dans dragonflybsd, les "variant symlinks", qui consistent en liens symboliques (ln -s toto tata) dont l'interprétation dépend du positionnement d'une variable d'environnement. Tu peux alors imaginer d'avoir des symlinks à variantes dans /usr/lib qui pointent sur des librairies différentes selon la manière dont on a positionné la variable d'environnement dans le script qui lance le programme. Mais tu peux faire pire. Tu peux imaginer un système de ports où quand on compile un paquet, tout y compris le choix du compilateur soit susceptible de variation par ce mécanisme.
Reste aussi à intégrer les correctifs d'un composants partagés.
--
Michel TALON
george
Michel Talon, dans le message <c537u0$2dru$, a écrit :
Je ne suis pas loin de penser que le système que préconise un autre posteur: mettre chaque programme dans sa propre directory avec tout le bazar dont il a besoin, tous ses fichiers de confs et de données est la meilleure solution, en d'autres termes, supprimer tout système de paquetage.
Occupation disque fois 5, occupation mémoire fois deux. Continue à donner des conseils aux BSDistes si tu veux, mais par pitié n'essaie pas de contribuer à une distribution Linux.
Michel Talon, dans le message <c537u0$2dru$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Je ne suis pas loin de penser que le système
que préconise un autre posteur: mettre chaque programme dans sa propre
directory avec tout le bazar dont il a besoin, tous ses fichiers de
confs et de données est la meilleure solution, en d'autres termes,
supprimer tout système de paquetage.
Occupation disque fois 5, occupation mémoire fois deux. Continue à
donner des conseils aux BSDistes si tu veux, mais par pitié n'essaie pas
de contribuer à une distribution Linux.
Michel Talon, dans le message <c537u0$2dru$, a écrit :
Je ne suis pas loin de penser que le système que préconise un autre posteur: mettre chaque programme dans sa propre directory avec tout le bazar dont il a besoin, tous ses fichiers de confs et de données est la meilleure solution, en d'autres termes, supprimer tout système de paquetage.
Occupation disque fois 5, occupation mémoire fois deux. Continue à donner des conseils aux BSDistes si tu veux, mais par pitié n'essaie pas de contribuer à une distribution Linux.
nicolas vigier
In article , Jerome Lambert wrote:
à version n+1, mais à ce rythme-là on rentre dans des procédés Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver à "comme la machine se traine, il faut en changer". Déja que ma machine tire la langue avec KDE 3.0, j'ose pas imaginer ce que ça donne avec KDE 4...
Il me semble que KDE 3.2 est plus rapide que KDE 3.0, qui est plus rapide que KDE 2.0. OpenOffice 1.1 est plus rapide que OpenOffice 1.0. Je crois qu'en general pour avoir une machine moins rapide qu'avant il faut changer de logiciels et pas uniquement de versions. Si tu installes une distribution recente sur une machine d'il y a 3 ans avec les memes logiciels qu'il y a 3 ans, je pense que ca sera aussi rapide qu'avant. Mais peu etre qu'il y a des exceptions ...
In article <pan.2004.04.08.09.25.37.262787@swing.aretirer.be>,
Jerome Lambert wrote:
à version n+1, mais à ce rythme-là on rentre dans des procédés
Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver
à "comme la machine se traine, il faut en changer".
Déja que ma machine tire la langue avec KDE 3.0, j'ose pas imaginer ce
que ça donne avec KDE 4...
Il me semble que KDE 3.2 est plus rapide que KDE 3.0, qui est plus rapide
que KDE 2.0. OpenOffice 1.1 est plus rapide que OpenOffice 1.0.
Je crois qu'en general pour avoir une machine moins rapide qu'avant il
faut changer de logiciels et pas uniquement de versions.
Si tu installes une distribution recente sur une machine d'il y a 3 ans avec
les memes logiciels qu'il y a 3 ans, je pense que ca sera aussi rapide
qu'avant. Mais peu etre qu'il y a des exceptions ...
à version n+1, mais à ce rythme-là on rentre dans des procédés Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver à "comme la machine se traine, il faut en changer". Déja que ma machine tire la langue avec KDE 3.0, j'ose pas imaginer ce que ça donne avec KDE 4...
Il me semble que KDE 3.2 est plus rapide que KDE 3.0, qui est plus rapide que KDE 2.0. OpenOffice 1.1 est plus rapide que OpenOffice 1.0. Je crois qu'en general pour avoir une machine moins rapide qu'avant il faut changer de logiciels et pas uniquement de versions. Si tu installes une distribution recente sur une machine d'il y a 3 ans avec les memes logiciels qu'il y a 3 ans, je pense que ca sera aussi rapide qu'avant. Mais peu etre qu'il y a des exceptions ...
Jerome Lambert
Le Thu, 08 Apr 2004 10:30:26 +0000, Nicolas George a écrit :
Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n à version n+1, mais à ce rythme-là on rentre dans des procédés Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver à "comme la machine se traine, il faut en changer".
Dis, tu lis et comprends ce que j'écris, ou ton cerveau est déjà en vacances ? Si tu veux installer le programme foo, et qu'il a besoin de la libbar version 42 ou plus, alors que tu n'as que la version 41, tu _dois_ installer une libbar 42, tu n'as pas le choix.
Donc j'installe libbar 42, qui nécessite libfoo 24 (on a la 22), qui, elle, est incluse dans progbar 15 (on a la 11), qui lui-même ... (on peut continuer longtemps comme ça), ce qui revient la plupart du temps à upgrader carrément (presque) toute la distribution.
Ecoute, ce que je décris est mon quotidien quand j'ai le malheur de vouloir installer un programme qui ne se trouve pas d'origine dans la distribution, et ce même quand j'ai choisi un rpm soi-disant prévu pour ma distribution.
Maintenant si tu as des solutions _pratiques_ à me donner, je suis à ta disposition, vu que sur le plan des principes je crois que n'arriverons jamais à être d'accord...
A propos, ta distribution magique qui, visiblement gère les dépendances comme un chef, c'est laquelle?
Jerome.
Le Thu, 08 Apr 2004 10:30:26 +0000, Nicolas George a écrit :
Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n
à version n+1, mais à ce rythme-là on rentre dans des procédés
Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver
à "comme la machine se traine, il faut en changer".
Dis, tu lis et comprends ce que j'écris, ou ton cerveau est déjà en
vacances ? Si tu veux installer le programme foo, et qu'il a besoin de
la libbar version 42 ou plus, alors que tu n'as que la version 41, tu
_dois_ installer une libbar 42, tu n'as pas le choix.
Donc j'installe libbar 42, qui nécessite libfoo 24 (on a la 22), qui,
elle, est incluse dans progbar 15 (on a la 11), qui lui-même ... (on peut
continuer longtemps comme ça), ce qui revient la plupart du temps à
upgrader carrément (presque) toute la distribution.
Ecoute, ce que je décris est mon quotidien quand j'ai le malheur de
vouloir installer un programme qui ne se trouve pas d'origine dans la
distribution, et ce même quand j'ai choisi un rpm soi-disant prévu pour
ma distribution.
Maintenant si tu as des solutions _pratiques_ à me donner, je suis à ta
disposition, vu que sur le plan des principes je crois que n'arriverons
jamais à être d'accord...
A propos, ta distribution magique qui, visiblement gère les dépendances
comme un chef, c'est laquelle?
Le Thu, 08 Apr 2004 10:30:26 +0000, Nicolas George a écrit :
Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n à version n+1, mais à ce rythme-là on rentre dans des procédés Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver à "comme la machine se traine, il faut en changer".
Dis, tu lis et comprends ce que j'écris, ou ton cerveau est déjà en vacances ? Si tu veux installer le programme foo, et qu'il a besoin de la libbar version 42 ou plus, alors que tu n'as que la version 41, tu _dois_ installer une libbar 42, tu n'as pas le choix.
Donc j'installe libbar 42, qui nécessite libfoo 24 (on a la 22), qui, elle, est incluse dans progbar 15 (on a la 11), qui lui-même ... (on peut continuer longtemps comme ça), ce qui revient la plupart du temps à upgrader carrément (presque) toute la distribution.
Ecoute, ce que je décris est mon quotidien quand j'ai le malheur de vouloir installer un programme qui ne se trouve pas d'origine dans la distribution, et ce même quand j'ai choisi un rpm soi-disant prévu pour ma distribution.
Maintenant si tu as des solutions _pratiques_ à me donner, je suis à ta disposition, vu que sur le plan des principes je crois que n'arriverons jamais à être d'accord...
A propos, ta distribution magique qui, visiblement gère les dépendances comme un chef, c'est laquelle?
Jerome.
Jerome Lambert
Le Thu, 08 Apr 2004 10:04:26 +0000, Michel Talon a écrit :
C'est vrai si tu parles de la unstable, mais si tu parles de la stable, laisse moi rire. Je n'ai jamais autant compilé que depuis que j'ai une Debian stable, et je ne parle pas de la prise de tête que c'est de faire des paquets .deb pour faire rentrer tout ça dans le moule.
J'ai dit "ensemble cohérent", j'ai pas dit "ensemble à jour". C'est aussi vrai que la première chose que j'ai faite avec la Debian, c'est la passer en unstable, parce que Mozilla 1.0 et Gnome 1.4, faut pas charrier...
Jerome.
Le Thu, 08 Apr 2004 10:04:26 +0000, Michel Talon a écrit :
C'est vrai si tu parles de la unstable, mais si tu parles de la stable,
laisse moi rire. Je n'ai jamais autant compilé que depuis que j'ai une
Debian stable, et je ne parle pas de la prise de tête que c'est de faire
des paquets .deb pour faire rentrer tout ça dans le moule.
J'ai dit "ensemble cohérent", j'ai pas dit "ensemble à jour".
C'est aussi vrai que la première chose que j'ai faite avec la Debian,
c'est la passer en unstable, parce que Mozilla 1.0 et Gnome 1.4, faut pas
charrier...
Le Thu, 08 Apr 2004 10:04:26 +0000, Michel Talon a écrit :
C'est vrai si tu parles de la unstable, mais si tu parles de la stable, laisse moi rire. Je n'ai jamais autant compilé que depuis que j'ai une Debian stable, et je ne parle pas de la prise de tête que c'est de faire des paquets .deb pour faire rentrer tout ça dans le moule.
J'ai dit "ensemble cohérent", j'ai pas dit "ensemble à jour". C'est aussi vrai que la première chose que j'ai faite avec la Debian, c'est la passer en unstable, parce que Mozilla 1.0 et Gnome 1.4, faut pas charrier...
Jerome.
Jerome Lambert
Le Thu, 08 Apr 2004 00:28:09 +0000, nicolas vigier a écrit :
Il y a mieux : http://zero-install.sourceforge.net/
Effectivement, ça a l'air pas mal!
Jerome.
Le Thu, 08 Apr 2004 00:28:09 +0000, nicolas vigier a écrit :
Il y a mieux :
http://zero-install.sourceforge.net/
