J'utilise actuellement Slackware mais je songe à changer pour Libranet
pour l'avantage de apt-get. Mais voilà que swaret et slapt-get arrivent
sur la scène.
Ces utilitaires s'occupent apparemment des dépendances. Ça fonctionne?
Il ne semble pas y avoir d'option pour désinstaller, dans swaret, en
tout cas.Est-ce que le système finit par être emcombré?
Est-ce vraiment possible de passer d'une version à l'autre de Slack en
cliquant un bouton comem swaret le prétend? Il y en a qui disent que
c'est un tout petit peu tiré par les cheveux, que l'auteur est un
abominable "péteux de broue".
Ensuite, il y a checkinstall qui permet apparemment de faire des tgz.
"Instead of the usual "make install" after compiling something, just do
a "checkinstall -S" and it will create and install the .tgz package for
you!"
Cf.: http://www.osnews.com/story.php?news_id=5307
Ici, le problème des dépendance n'est pas réglé, mais celui d'enlever
les paquets, oui... apparemment.
Ce qui inquéte un peu dans tout ça, c'est que ces outils se développent
indépendamment et que Volkerding ne donne jamais son opinion. Ça beau
être de l'open source, je doute qu'il soit toujours lu et strictement
contrôlé.
En d'autres mots, en plus d'être un soft plus sous contrôle, est-ce que
apt-get a des années-lumières d'avance ou seulement une année ou deux :)
D'autre part, le boot SysV m'a l'air terriblement compliqué et je ne
vois pas ce que ça donne de plus. TOUT m'a l'air plus compliqué, même
les scripts. Dans Slackware ils se lisent presque comme du français, en
comparaison.
Je sais que je n'opterai pas pour Mandrake, Suse, Lindows ou quelque
merde du genre, mais entre Slack et Libranet,je suis paire plexe :)
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
On Wed, 10 Dec 2003 13:08:30 +0000 (UTC), Michel Talon wrote:
Si tu gardes postfix et exim, sur quoi pointe /usr/sbin/sendmail ? Et /usr/bin/newaliases ? Où est la connerie monstrueuse puisqu'il suffit de refaire apt-get install exim si l'on veut de nouveau exim ?
Et où est le problème de conserver les binaires de exim et de postfix sur la machine et de se contenter de déplacer le lien symbolique.
Il n'y a pas vraiment de problème, si ce n'est que ce ne sont pas des liens symboliques. De plus (et là je suppose que c'est vraiment chacun son avis) il y a tellement de liens symboliques à gérer suivant les MTA que seul un outil de plus haut niveau permettra de ne pas s'emmêler les pinceaux.
Ce n'est pas parceque j'ai voulu essayer postfix que je veux me débarrasser de exim, aprés tout. Oui on peut réinstaller, à condition de ne pas avoir fait un clean entre temps et d'être connecté au réseau.
Certes ; on peut aussi conserver les packages qu'on installe et désinstalle souvent (c'est ce que je fais avec les différentes versions de flex par exemple). Finalement, garder des versions compilées sous forme de package dans un endroit de son système, ça n'est pas si éloigné de garder des versions compilées installées sur son système.
Il est vrai que des power users voudraient parfois aller beaucoup plus loin que le système de dépendances des packages ; pour ceux-là il y a toujours des solutions (installer les packages dans un chroot, utiliser le système de diversion de dpkg, refaire son propre package en modifiant les conflits...). Et là je ne trouve pas anormal qu'il faille un peu réfléchir. Il y a forcément des garde-fous dans un système de dépendances, mais ils sont à ma connaissance tous contournables, et en tout cas ni aussi nombreux ni aussi rhédibitoire que ce que l'on laisse souvent croire.
J'espère bien. Le problème c'est si tu installes un nouveau logiciel qui installe une nouvelle version d'une lib et qu'autoritairement on te vire la vieille sous prétexte qu'elle n'a plus de programme dépendant. Je sais que ce genre de gag est arrivé avec portupgrade dans FreeBSD au sujet du GNU gettext, et que plein de gens se sont retrouvés avec la moitié des ports qui ne fonctionnaient plus car ils n'avaient plus la bonne version de libintl.
C'est bizarre ça, non ? D'après ce que je comprends, il n'y avait plus de programme dépendant de l'ancienne libintl, mais ça a cassé des ports ? Il y a forcément l'expression d'une dépendance qui manquait quelque part ..
Voilà ce qui arrive quand un logiciel de gestion des dépendances veut être trop malin. A mon avis la seule bonne solution est d'accumuler toutes les versions des librairies. C'est la solution qui était traditionnellement employée dans FreeBSD et qui garantissait la compatibilité ascendante. Grace à ça j'ai pu passer de la version 2.2.5 à la version 4.8 en suivant toutes les versions, le passage de a.out à elf, etc. avec tout qui continuait à marcher, le vieux programmes comme les nouveaux.
Je suis entièrement d'accord avec cela.
-- Sam.
On Wed, 10 Dec 2003 13:08:30 +0000 (UTC), Michel Talon wrote:
Si tu gardes postfix et exim, sur quoi pointe /usr/sbin/sendmail ?
Et /usr/bin/newaliases ? Où est la connerie monstrueuse puisqu'il suffit
de refaire apt-get install exim si l'on veut de nouveau exim ?
Et où est le problème de conserver les binaires de exim et de postfix
sur la machine et de se contenter de déplacer le lien symbolique.
Il n'y a pas vraiment de problème, si ce n'est que ce ne sont pas des
liens symboliques. De plus (et là je suppose que c'est vraiment chacun
son avis) il y a tellement de liens symboliques à gérer suivant les MTA
que seul un outil de plus haut niveau permettra de ne pas s'emmêler les
pinceaux.
Ce n'est pas parceque j'ai voulu essayer postfix que je veux me débarrasser
de exim, aprés tout. Oui on peut réinstaller, à condition de ne pas
avoir fait un clean entre temps et d'être connecté au réseau.
Certes ; on peut aussi conserver les packages qu'on installe et
désinstalle souvent (c'est ce que je fais avec les différentes versions
de flex par exemple). Finalement, garder des versions compilées sous
forme de package dans un endroit de son système, ça n'est pas si éloigné
de garder des versions compilées installées sur son système.
Il est vrai que des power users voudraient parfois aller beaucoup
plus loin que le système de dépendances des packages ; pour ceux-là il y
a toujours des solutions (installer les packages dans un chroot,
utiliser le système de diversion de dpkg, refaire son propre package en
modifiant les conflits...). Et là je ne trouve pas anormal qu'il faille
un peu réfléchir. Il y a forcément des garde-fous dans un système de
dépendances, mais ils sont à ma connaissance tous contournables, et en
tout cas ni aussi nombreux ni aussi rhédibitoire que ce que l'on laisse
souvent croire.
J'espère bien. Le problème c'est si tu installes un nouveau logiciel qui
installe une nouvelle version d'une lib et qu'autoritairement on te vire
la vieille sous prétexte qu'elle n'a plus de programme dépendant. Je
sais que ce genre de gag est arrivé avec portupgrade dans FreeBSD au
sujet du GNU gettext, et que plein de gens se sont retrouvés avec la
moitié des ports qui ne fonctionnaient plus car ils n'avaient plus la
bonne version de libintl.
C'est bizarre ça, non ? D'après ce que je comprends, il n'y avait
plus de programme dépendant de l'ancienne libintl, mais ça a cassé des
ports ? Il y a forcément l'expression d'une dépendance qui manquait
quelque part ..
Voilà ce qui arrive quand un logiciel de
gestion des dépendances veut être trop malin. A mon avis la seule bonne
solution est d'accumuler toutes les versions des librairies. C'est la
solution qui était traditionnellement employée dans FreeBSD et qui
garantissait la compatibilité ascendante. Grace à ça j'ai pu passer de
la version 2.2.5 à la version 4.8 en suivant toutes les versions, le
passage de a.out à elf, etc. avec tout qui continuait à marcher, le
vieux programmes comme les nouveaux.
On Wed, 10 Dec 2003 13:08:30 +0000 (UTC), Michel Talon wrote:
Si tu gardes postfix et exim, sur quoi pointe /usr/sbin/sendmail ? Et /usr/bin/newaliases ? Où est la connerie monstrueuse puisqu'il suffit de refaire apt-get install exim si l'on veut de nouveau exim ?
Et où est le problème de conserver les binaires de exim et de postfix sur la machine et de se contenter de déplacer le lien symbolique.
Il n'y a pas vraiment de problème, si ce n'est que ce ne sont pas des liens symboliques. De plus (et là je suppose que c'est vraiment chacun son avis) il y a tellement de liens symboliques à gérer suivant les MTA que seul un outil de plus haut niveau permettra de ne pas s'emmêler les pinceaux.
Ce n'est pas parceque j'ai voulu essayer postfix que je veux me débarrasser de exim, aprés tout. Oui on peut réinstaller, à condition de ne pas avoir fait un clean entre temps et d'être connecté au réseau.
Certes ; on peut aussi conserver les packages qu'on installe et désinstalle souvent (c'est ce que je fais avec les différentes versions de flex par exemple). Finalement, garder des versions compilées sous forme de package dans un endroit de son système, ça n'est pas si éloigné de garder des versions compilées installées sur son système.
Il est vrai que des power users voudraient parfois aller beaucoup plus loin que le système de dépendances des packages ; pour ceux-là il y a toujours des solutions (installer les packages dans un chroot, utiliser le système de diversion de dpkg, refaire son propre package en modifiant les conflits...). Et là je ne trouve pas anormal qu'il faille un peu réfléchir. Il y a forcément des garde-fous dans un système de dépendances, mais ils sont à ma connaissance tous contournables, et en tout cas ni aussi nombreux ni aussi rhédibitoire que ce que l'on laisse souvent croire.
J'espère bien. Le problème c'est si tu installes un nouveau logiciel qui installe une nouvelle version d'une lib et qu'autoritairement on te vire la vieille sous prétexte qu'elle n'a plus de programme dépendant. Je sais que ce genre de gag est arrivé avec portupgrade dans FreeBSD au sujet du GNU gettext, et que plein de gens se sont retrouvés avec la moitié des ports qui ne fonctionnaient plus car ils n'avaient plus la bonne version de libintl.
C'est bizarre ça, non ? D'après ce que je comprends, il n'y avait plus de programme dépendant de l'ancienne libintl, mais ça a cassé des ports ? Il y a forcément l'expression d'une dépendance qui manquait quelque part ..
Voilà ce qui arrive quand un logiciel de gestion des dépendances veut être trop malin. A mon avis la seule bonne solution est d'accumuler toutes les versions des librairies. C'est la solution qui était traditionnellement employée dans FreeBSD et qui garantissait la compatibilité ascendante. Grace à ça j'ai pu passer de la version 2.2.5 à la version 4.8 en suivant toutes les versions, le passage de a.out à elf, etc. avec tout qui continuait à marcher, le vieux programmes comme les nouveaux.
Je suis entièrement d'accord avec cela.
-- Sam.
Sam Hocevar
On Wed, 10 Dec 2003 13:32:47 +0000 (UTC), Nicolas George wrote:
[...]
Que devient libfoo dans tout ça ? Il est clair qu'ils doivent fournir une libfoo.so.1 liée avec libc.so.1, pour la compatibilité. Ils voudront cependant certainement fournir une version de la libfoo liée avec libc.so.2. Comment l'appeler ? Ils sont *obligés* de changer le SONAME.
Euh, non, ils l'appellent libfoo.so.1 liée avec libc.so.2, et ils font un plan de transition pour tout upgrader en même temps, comme le font toutes les distributions Linux. C'est ce qui se fait à chaque fois que la libstdc++ change, par exemple. Quand c'est carrément la libc qui change, on peut s'aider du dynamic linker et lui dire de choisir la bonne librairie : on peut par exemple avoir un /usr/lib/libfoo.so.1 lié avec libc.so.2, et un /usr/oldlib/libfoo.so.1 lié avec libc.so.1.
Pourtant, libfoo n'a pas bougé d'un pouce, et je ne vais certainement pas changer le SONAME par défaut pour ce BarOS que je ne connais même pas.
Ton exemple est intéressant, mais il n'est vraiment pas très générique : il n'y a guère que la libc qui va changer de manière non-uniforme ; pour les autres librairies, si l'une d'elles change, il y a tout à fait lieu de changer le SONAME de libfoo.
Ça te semble tiré par les cheveux ?
Non pas du tout, c'est très pertinent. Mais ton exemple n'est pas très extensible : il n'y a guère que la libc qui va changer de façon différente suivant l'OS. Pour tout le reste, je pense qu'un changement de SONAME upstream est nécessaire.
Remplace BarOS par FreeBSD : la libc change de SONAME à chaque release majeure.
Eh oui, c'est pour cela que d'autres utilisent des versioned symbols pour éviter ces problèmes (même si ça a aussi ses désagréments).
Sam. -- Sam Hocevar <http://sam.zoy.org/>
On Wed, 10 Dec 2003 13:32:47 +0000 (UTC), Nicolas George wrote:
[...]
Que devient libfoo dans tout ça ? Il est clair qu'ils doivent fournir
une libfoo.so.1 liée avec libc.so.1, pour la compatibilité. Ils voudront
cependant certainement fournir une version de la libfoo liée avec
libc.so.2. Comment l'appeler ? Ils sont *obligés* de changer le SONAME.
Euh, non, ils l'appellent libfoo.so.1 liée avec libc.so.2, et ils
font un plan de transition pour tout upgrader en même temps, comme le
font toutes les distributions Linux. C'est ce qui se fait à chaque fois
que la libstdc++ change, par exemple. Quand c'est carrément la libc qui
change, on peut s'aider du dynamic linker et lui dire de choisir la
bonne librairie : on peut par exemple avoir un /usr/lib/libfoo.so.1 lié
avec libc.so.2, et un /usr/oldlib/libfoo.so.1 lié avec libc.so.1.
Pourtant, libfoo n'a pas bougé d'un pouce, et je ne vais certainement
pas changer le SONAME par défaut pour ce BarOS que je ne connais même
pas.
Ton exemple est intéressant, mais il n'est vraiment pas très
générique : il n'y a guère que la libc qui va changer de manière
non-uniforme ; pour les autres librairies, si l'une d'elles change, il y
a tout à fait lieu de changer le SONAME de libfoo.
Ça te semble tiré par les cheveux ?
Non pas du tout, c'est très pertinent. Mais ton exemple n'est pas
très extensible : il n'y a guère que la libc qui va changer de façon
différente suivant l'OS. Pour tout le reste, je pense qu'un changement
de SONAME upstream est nécessaire.
Remplace BarOS par FreeBSD : la
libc change de SONAME à chaque release majeure.
Eh oui, c'est pour cela que d'autres utilisent des versioned symbols
pour éviter ces problèmes (même si ça a aussi ses désagréments).
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Wed, 10 Dec 2003 13:32:47 +0000 (UTC), Nicolas George wrote:
[...]
Que devient libfoo dans tout ça ? Il est clair qu'ils doivent fournir une libfoo.so.1 liée avec libc.so.1, pour la compatibilité. Ils voudront cependant certainement fournir une version de la libfoo liée avec libc.so.2. Comment l'appeler ? Ils sont *obligés* de changer le SONAME.
Euh, non, ils l'appellent libfoo.so.1 liée avec libc.so.2, et ils font un plan de transition pour tout upgrader en même temps, comme le font toutes les distributions Linux. C'est ce qui se fait à chaque fois que la libstdc++ change, par exemple. Quand c'est carrément la libc qui change, on peut s'aider du dynamic linker et lui dire de choisir la bonne librairie : on peut par exemple avoir un /usr/lib/libfoo.so.1 lié avec libc.so.2, et un /usr/oldlib/libfoo.so.1 lié avec libc.so.1.
Pourtant, libfoo n'a pas bougé d'un pouce, et je ne vais certainement pas changer le SONAME par défaut pour ce BarOS que je ne connais même pas.
Ton exemple est intéressant, mais il n'est vraiment pas très générique : il n'y a guère que la libc qui va changer de manière non-uniforme ; pour les autres librairies, si l'une d'elles change, il y a tout à fait lieu de changer le SONAME de libfoo.
Ça te semble tiré par les cheveux ?
Non pas du tout, c'est très pertinent. Mais ton exemple n'est pas très extensible : il n'y a guère que la libc qui va changer de façon différente suivant l'OS. Pour tout le reste, je pense qu'un changement de SONAME upstream est nécessaire.
Remplace BarOS par FreeBSD : la libc change de SONAME à chaque release majeure.
Eh oui, c'est pour cela que d'autres utilisent des versioned symbols pour éviter ces problèmes (même si ça a aussi ses désagréments).
Sam. -- Sam Hocevar <http://sam.zoy.org/>
george
Sam Hocevar , dans le message <slrnbtear1.3ld.sam+, a écrit :
Euh, non, ils l'appellent libfoo.so.1 liée avec libc.so.2, et ils font un plan de transition pour tout upgrader en même temps, comme le font toutes les distributions Linux.
Qu'est-ce que tu appelles « plan de transition » ?
Garde l'exemple précédent, et condidère quelqu'un qui a un binaire qux compilé maison sur BarOS 1.x : qux a libc.so.1 et libfoo.so.1 en NEEDED. Upgrade de BarOS, qux ne bouge pa (on ne va pas tout recompiler à chaque upgrade !) : il a toujours libfoo.so.1 et libc.so.1. Si la version de libfoo compilée avec libc.so.2 s'appelle encore libfoo.so.1, alors c'est elle qui va être chargée, et ça va faire très mal :
- soit libfoo.so.1 comporte un NEEDED libc.so.2, dans ce cas qux va charger *deux* exemplaires de la libc, mutuellement incompatibles, et il est à peu près impossible de prévoir quelle version va fournir les symboles (parfois pas tous la même) ; ça peut même marcher ;
- soit libfoo.so.1 ne comporte pas de NEEDED, dans ce cas seule libc.so.1 va être chargée à cause du NEEDED de qux, ete ça va chier dès que libfoo (compilée avec libc.so.2, je le rappelle) va appeler des fonctions de la libc qui ont changé d'ABI.
Eh oui, c'est pour cela que d'autres utilisent des versioned symbols pour éviter ces problèmes (même si ça a aussi ses désagréments).
J'espère que tu savoures la chance que tu as de gérer des paquets basés sur la glibc...
Sam Hocevar , dans le message <slrnbtear1.3ld.sam+news@poulet.zoy.org>,
a écrit :
Euh, non, ils l'appellent libfoo.so.1 liée avec libc.so.2, et ils
font un plan de transition pour tout upgrader en même temps, comme le
font toutes les distributions Linux.
Qu'est-ce que tu appelles « plan de transition » ?
Garde l'exemple précédent, et condidère quelqu'un qui a un binaire qux
compilé maison sur BarOS 1.x : qux a libc.so.1 et libfoo.so.1 en
NEEDED. Upgrade de BarOS, qux ne bouge pa (on ne va pas tout recompiler
à chaque upgrade !) : il a toujours libfoo.so.1 et libc.so.1. Si la
version de libfoo compilée avec libc.so.2 s'appelle encore libfoo.so.1,
alors c'est elle qui va être chargée, et ça va faire très mal :
- soit libfoo.so.1 comporte un NEEDED libc.so.2, dans ce cas qux va
charger *deux* exemplaires de la libc, mutuellement incompatibles, et
il est à peu près impossible de prévoir quelle version va fournir les
symboles (parfois pas tous la même) ; ça peut même marcher ;
- soit libfoo.so.1 ne comporte pas de NEEDED, dans ce cas seule
libc.so.1 va être chargée à cause du NEEDED de qux, ete ça va chier
dès que libfoo (compilée avec libc.so.2, je le rappelle) va appeler
des fonctions de la libc qui ont changé d'ABI.
Eh oui, c'est pour cela que d'autres utilisent des versioned symbols
pour éviter ces problèmes (même si ça a aussi ses désagréments).
J'espère que tu savoures la chance que tu as de gérer des paquets basés
sur la glibc...
Sam Hocevar , dans le message <slrnbtear1.3ld.sam+, a écrit :
Euh, non, ils l'appellent libfoo.so.1 liée avec libc.so.2, et ils font un plan de transition pour tout upgrader en même temps, comme le font toutes les distributions Linux.
Qu'est-ce que tu appelles « plan de transition » ?
Garde l'exemple précédent, et condidère quelqu'un qui a un binaire qux compilé maison sur BarOS 1.x : qux a libc.so.1 et libfoo.so.1 en NEEDED. Upgrade de BarOS, qux ne bouge pa (on ne va pas tout recompiler à chaque upgrade !) : il a toujours libfoo.so.1 et libc.so.1. Si la version de libfoo compilée avec libc.so.2 s'appelle encore libfoo.so.1, alors c'est elle qui va être chargée, et ça va faire très mal :
- soit libfoo.so.1 comporte un NEEDED libc.so.2, dans ce cas qux va charger *deux* exemplaires de la libc, mutuellement incompatibles, et il est à peu près impossible de prévoir quelle version va fournir les symboles (parfois pas tous la même) ; ça peut même marcher ;
- soit libfoo.so.1 ne comporte pas de NEEDED, dans ce cas seule libc.so.1 va être chargée à cause du NEEDED de qux, ete ça va chier dès que libfoo (compilée avec libc.so.2, je le rappelle) va appeler des fonctions de la libc qui ont changé d'ABI.
Eh oui, c'est pour cela que d'autres utilisent des versioned symbols pour éviter ces problèmes (même si ça a aussi ses désagréments).
J'espère que tu savoures la chance que tu as de gérer des paquets basés sur la glibc...
Emmanuel Florac
Dans article <3fd67a60$, disait...
Ne gère que les installs? Alors, si tu désinstalles un packet, toutes les dépendances restent là? Et si tu fais un upgrade d'un package et que le nouveau emploie une nouvelle version des mêmes librairies, les anciennes restent là?
Non, les anciennes sont upgradées SI NECESSAIRE.
Je viens de jeter un coup d'oeil à slapt-get, et il semble bien que ce soit la même chose: install seulement. Cf.:
http://freshmeat.net/releases/138900/
Ah? Par contre swaret ne gère pour l'instant que les miroirs slack, par contre slapt-get peut installer tout packages (depuis linuxpâckages.net par exemple).
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret ou slapt-get en même temps?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple Gnome depuis les sources en faisant tes propres packages, swaret en tiendra compte puisqu'il vérifie les dép au niveau librairies.
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est désinstallé et le paquet Debian mis à la place , grrrr.
Alors, peut-on dire que la différence entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
Oui, essentiellement.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fd67a60$1_8@corp.newsgroups.com>,
gilpel@inverse.nretla.org disait...
Ne gère que les installs? Alors, si tu désinstalles un packet, toutes
les dépendances restent là? Et si tu fais un upgrade d'un package et
que le nouveau emploie une nouvelle version des mêmes librairies, les
anciennes restent là?
Non, les anciennes sont upgradées SI NECESSAIRE.
Je viens de jeter un coup d'oeil à slapt-get, et il semble bien que ce
soit la même chose: install seulement. Cf.:
http://freshmeat.net/releases/138900/
Ah? Par contre swaret ne gère pour l'instant que les miroirs slack, par
contre slapt-get peut installer tout packages (depuis linuxpâckages.net
par exemple).
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret
ou slapt-get en même temps?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple
Gnome depuis les sources en faisant tes propres packages, swaret en
tiendra compte puisqu'il vérifie les dép au niveau librairies.
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer
webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est
désinstallé et le paquet Debian mis à la place , grrrr.
Alors, peut-on dire que la différence
entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
Oui, essentiellement.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Ne gère que les installs? Alors, si tu désinstalles un packet, toutes les dépendances restent là? Et si tu fais un upgrade d'un package et que le nouveau emploie une nouvelle version des mêmes librairies, les anciennes restent là?
Non, les anciennes sont upgradées SI NECESSAIRE.
Je viens de jeter un coup d'oeil à slapt-get, et il semble bien que ce soit la même chose: install seulement. Cf.:
http://freshmeat.net/releases/138900/
Ah? Par contre swaret ne gère pour l'instant que les miroirs slack, par contre slapt-get peut installer tout packages (depuis linuxpâckages.net par exemple).
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret ou slapt-get en même temps?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple Gnome depuis les sources en faisant tes propres packages, swaret en tiendra compte puisqu'il vérifie les dép au niveau librairies.
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est désinstallé et le paquet Debian mis à la place , grrrr.
Alors, peut-on dire que la différence entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
Oui, essentiellement.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Thierry Thomas
Mercredi 10 décembre 2003 à 13:57 GMT, Sam Hocevar a écrit :
J'espère bien. Le problème c'est si tu installes un nouveau logiciel qui installe une nouvelle version d'une lib et qu'autoritairement on te vire la vieille sous prétexte qu'elle n'a plus de programme dépendant. Je sais que ce genre de gag est arrivé avec portupgrade dans FreeBSD au sujet du GNU gettext, et que plein de gens se sont retrouvés avec la moitié des ports qui ne fonctionnaient plus car ils n'avaient plus la bonne version de libintl.
C'est bizarre ça, non ? D'après ce que je comprends, il n'y avait plus de programme dépendant de l'ancienne libintl, mais ça a cassé des ports ? Il y a forcément l'expression d'une dépendance qui manquait quelque part ..
C'est parce que lorsqu'on met à jour une lib utilisée par un grand nombre de ports, comme gettext, ça conduit à recompiler tout ces ports, ou à réinstaller les nouveaux packages, et il y en a toujours qui essayent de ruser pour y échapper. -- Th. Thomas.
Mercredi 10 décembre 2003 à 13:57 GMT, Sam Hocevar a écrit :
J'espère bien. Le problème c'est si tu installes un nouveau logiciel qui
installe une nouvelle version d'une lib et qu'autoritairement on te vire
la vieille sous prétexte qu'elle n'a plus de programme dépendant. Je
sais que ce genre de gag est arrivé avec portupgrade dans FreeBSD au
sujet du GNU gettext, et que plein de gens se sont retrouvés avec la
moitié des ports qui ne fonctionnaient plus car ils n'avaient plus la
bonne version de libintl.
C'est bizarre ça, non ? D'après ce que je comprends, il n'y avait
plus de programme dépendant de l'ancienne libintl, mais ça a cassé des
ports ? Il y a forcément l'expression d'une dépendance qui manquait
quelque part ..
C'est parce que lorsqu'on met à jour une lib utilisée par un grand
nombre de ports, comme gettext, ça conduit à recompiler tout ces ports,
ou à réinstaller les nouveaux packages, et il y en a toujours qui
essayent de ruser pour y échapper.
--
Th. Thomas.
Mercredi 10 décembre 2003 à 13:57 GMT, Sam Hocevar a écrit :
J'espère bien. Le problème c'est si tu installes un nouveau logiciel qui installe une nouvelle version d'une lib et qu'autoritairement on te vire la vieille sous prétexte qu'elle n'a plus de programme dépendant. Je sais que ce genre de gag est arrivé avec portupgrade dans FreeBSD au sujet du GNU gettext, et que plein de gens se sont retrouvés avec la moitié des ports qui ne fonctionnaient plus car ils n'avaient plus la bonne version de libintl.
C'est bizarre ça, non ? D'après ce que je comprends, il n'y avait plus de programme dépendant de l'ancienne libintl, mais ça a cassé des ports ? Il y a forcément l'expression d'une dépendance qui manquait quelque part ..
C'est parce que lorsqu'on met à jour une lib utilisée par un grand nombre de ports, comme gettext, ça conduit à recompiler tout ces ports, ou à réinstaller les nouveaux packages, et il y en a toujours qui essayent de ruser pour y échapper. -- Th. Thomas.
GP
Emmanuel Florac wrote:
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret ou slapt-get en même temps?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple Gnome depuis les sources en faisant tes propres packages, swaret en tiendra compte puisqu'il vérifie les dép au niveau librairies.
Je ne me vois pas trop faire un ungrade dedistro de cette façon :)
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est désinstallé et le paquet Debian mis à la place , grrrr.
Ça, ça va de soi!
Alors, peut-on dire que la différence entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
Oui, essentiellement.
Merci de tous les renseignements. Quand je vais avoir un peu de temps, je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à jour un soft avec slapt-get et swaret, et voir comment ça se passe comparativement à avec apt-get. Puis, ce sera le temps de prendre une décision.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Emmanuel Florac wrote:
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret
ou slapt-get en même temps?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple
Gnome depuis les sources en faisant tes propres packages, swaret en
tiendra compte puisqu'il vérifie les dép au niveau librairies.
Je ne me vois pas trop faire un ungrade dedistro de cette façon :)
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer
webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est
désinstallé et le paquet Debian mis à la place , grrrr.
Ça, ça va de soi!
Alors, peut-on dire que la différence
entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
Oui, essentiellement.
Merci de tous les renseignements. Quand je vais avoir un peu de temps,
je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à
jour un soft avec slapt-get et swaret, et voir comment ça se passe
comparativement à avec apt-get. Puis, ce sera le temps de prendre une
décision.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret ou slapt-get en même temps?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple Gnome depuis les sources en faisant tes propres packages, swaret en tiendra compte puisqu'il vérifie les dép au niveau librairies.
Je ne me vois pas trop faire un ungrade dedistro de cette façon :)
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est désinstallé et le paquet Debian mis à la place , grrrr.
Ça, ça va de soi!
Alors, peut-on dire que la différence entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
Oui, essentiellement.
Merci de tous les renseignements. Quand je vais avoir un peu de temps, je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à jour un soft avec slapt-get et swaret, et voir comment ça se passe comparativement à avec apt-get. Puis, ce sera le temps de prendre une décision.
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Emmanuel Florac
Dans article <3fd7a5d3$, disait...
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple Gnome depuis les sources en faisant tes propres packages, swaret en tiendra compte puisqu'il vérifie les dép au niveau librairies.
Je ne me vois pas trop faire un ungrade dedistro de cette façon :)
Non, mais par exemple tu peux installer le Gnome de nos amis de dropline.net en lieu et place du gnome officiel de la slack (c'est même vivement recommandé si tu utilises gnome desktop) sans entraîner de problèmes de dépendances.
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est désinstallé et le paquet Debian mis à la place , grrrr.
Ça, ça va de soi!
Ben non. Ce qui irait de soi c'est qu'en voyant un paquet incompatible, il proteste mais n'y touche pas. Hors il proteste mais il l'efface sans me laisser d'autre choix, puis installe sa merde à lui et plante tout : ensuite je suis obligé de tout désinstaller à la main et de réinstaller mon paquet, super.
Merci de tous les renseignements. Quand je vais avoir un peu de temps, je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à jour un soft avec slapt-get et swaret, et voir comment ça se passe comparativement à avec apt-get. Puis, ce sera le temps de prendre une décision.
Bonne chance.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fd7a5d3$1_7@corp.newsgroups.com>,
gilpel@inverse.nretla.org disait...
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple
Gnome depuis les sources en faisant tes propres packages, swaret en
tiendra compte puisqu'il vérifie les dép au niveau librairies.
Je ne me vois pas trop faire un ungrade dedistro de cette façon :)
Non, mais par exemple tu peux installer le Gnome de nos amis de
dropline.net en lieu et place du gnome officiel de la slack (c'est même
vivement recommandé si tu utilises gnome desktop) sans entraîner de
problèmes de dépendances.
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer
webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est
désinstallé et le paquet Debian mis à la place , grrrr.
Ça, ça va de soi!
Ben non. Ce qui irait de soi c'est qu'en voyant un paquet incompatible,
il proteste mais n'y touche pas. Hors il proteste mais il l'efface sans
me laisser d'autre choix, puis installe sa merde à lui et plante tout :
ensuite je suis obligé de tout désinstaller à la main et de réinstaller
mon paquet, super.
Merci de tous les renseignements. Quand je vais avoir un peu de temps,
je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à
jour un soft avec slapt-get et swaret, et voir comment ça se passe
comparativement à avec apt-get. Puis, ce sera le temps de prendre une
décision.
Bonne chance.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Mais si bien sûr, il n'y a aucun problème. Si tu installes par exemple Gnome depuis les sources en faisant tes propres packages, swaret en tiendra compte puisqu'il vérifie les dép au niveau librairies.
Je ne me vois pas trop faire un ungrade dedistro de cette façon :)
Non, mais par exemple tu peux installer le Gnome de nos amis de dropline.net en lieu et place du gnome officiel de la slack (c'est même vivement recommandé si tu utilises gnome desktop) sans entraîner de problèmes de dépendances.
A contrario, j'ai essayé de faire un paquet Debian à moi pour installer webmin : quand je fais apt-get dist-upgrade, mon paquet webmin est désinstallé et le paquet Debian mis à la place , grrrr.
Ça, ça va de soi!
Ben non. Ce qui irait de soi c'est qu'en voyant un paquet incompatible, il proteste mais n'y touche pas. Hors il proteste mais il l'efface sans me laisser d'autre choix, puis installe sa merde à lui et plante tout : ensuite je suis obligé de tout désinstaller à la main et de réinstaller mon paquet, super.
Merci de tous les renseignements. Quand je vais avoir un peu de temps, je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à jour un soft avec slapt-get et swaret, et voir comment ça se passe comparativement à avec apt-get. Puis, ce sera le temps de prendre une décision.
Bonne chance.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Vincent Bernat
OoO Vers la fin de l'après-midi du mercredi 10 décembre 2003, vers 16:37, Emmanuel Florac disait:
Ben non. Ce qui irait de soi c'est qu'en voyant un paquet incompatible, il proteste mais n'y touche pas. Hors il proteste mais il l'efface sans me laisser d'autre choix, puis installe sa merde à lui et plante tout : ensuite je suis obligé de tout désinstaller à la main et de réinstaller mon paquet, super.
Je ne vois pas par quelle opération du saint esprit il peut deviner que ce paquet est incompatible. Soit tu le précises, soit tu donnes un autre numéro de version, soit tu le places en hold, soit tu le pin-point de manière appropriée. Perso, je place les paquets que je veux pas upgrader en hold, ça me semble le plus simple. Touche "=" dans aptitude. -- BOFH excuse #141: disks spinning backwards - toggle the hemisphere jumper.
OoO Vers la fin de l'après-midi du mercredi 10 décembre 2003, vers
16:37, Emmanuel Florac <eflorac@verisign.com> disait:
Ben non. Ce qui irait de soi c'est qu'en voyant un paquet incompatible,
il proteste mais n'y touche pas. Hors il proteste mais il l'efface sans
me laisser d'autre choix, puis installe sa merde à lui et plante tout :
ensuite je suis obligé de tout désinstaller à la main et de réinstaller
mon paquet, super.
Je ne vois pas par quelle opération du saint esprit il peut deviner
que ce paquet est incompatible. Soit tu le précises, soit tu donnes
un autre numéro de version, soit tu le places en hold, soit tu le
pin-point de manière appropriée. Perso, je place les paquets que je
veux pas upgrader en hold, ça me semble le plus simple. Touche "="
dans aptitude.
--
BOFH excuse #141:
disks spinning backwards - toggle the hemisphere jumper.
OoO Vers la fin de l'après-midi du mercredi 10 décembre 2003, vers 16:37, Emmanuel Florac disait:
Ben non. Ce qui irait de soi c'est qu'en voyant un paquet incompatible, il proteste mais n'y touche pas. Hors il proteste mais il l'efface sans me laisser d'autre choix, puis installe sa merde à lui et plante tout : ensuite je suis obligé de tout désinstaller à la main et de réinstaller mon paquet, super.
Je ne vois pas par quelle opération du saint esprit il peut deviner que ce paquet est incompatible. Soit tu le précises, soit tu donnes un autre numéro de version, soit tu le places en hold, soit tu le pin-point de manière appropriée. Perso, je place les paquets que je veux pas upgrader en hold, ça me semble le plus simple. Touche "=" dans aptitude. -- BOFH excuse #141: disks spinning backwards - toggle the hemisphere jumper.
GP
Emmanuel Florac wrote:
Merci de tous les renseignements. Quand je vais avoir un peu de temps, je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à jour un soft avec slapt-get et swaret, et voir comment ça se passe comparativement à avec apt-get. Puis, ce sera le temps de prendre une décision.
Bonne chance.
Merci! Qui qu'il arrive, je devrais survivre. En tout cas, ce n'est pas ce qui va me tuer :)
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Emmanuel Florac wrote:
Merci de tous les renseignements. Quand je vais avoir un peu de temps,
je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à
jour un soft avec slapt-get et swaret, et voir comment ça se passe
comparativement à avec apt-get. Puis, ce sera le temps de prendre une
décision.
Bonne chance.
Merci! Qui qu'il arrive, je devrais survivre. En tout cas, ce n'est
pas ce qui va me tuer :)
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Merci de tous les renseignements. Quand je vais avoir un peu de temps, je vais jeter un coup d'oeil à la dic suggérée, essayer de mettre à jour un soft avec slapt-get et swaret, et voir comment ça se passe comparativement à avec apt-get. Puis, ce sera le temps de prendre une décision.
Bonne chance.
Merci! Qui qu'il arrive, je devrais survivre. En tout cas, ce n'est pas ce qui va me tuer :)
GP
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Emmanuel Florac
Dans article , disait...
Je ne vois pas par quelle opération du saint esprit il peut deviner que ce paquet est incompatible.
Pourtant il me dit "un paquet wqebmin version machin incompatiblme a été trouvé. Ce paquet sera désinstaller, et là j'ai juste <OK>" (dans apt-get ou synaptic).
Soit tu le précises, soit tu donnes un autre numéro de version, soit tu le places en hold, soit tu le pin-point de manière appropriée. Perso, je place les paquets que je veux pas upgrader en hold, ça me semble le plus simple. Touche "=" dans aptitude.
Et dans apt-get ou dpkg?
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <m33cbsb1sk.fsf@neo.loria>, vince@khabale.org disait...
Je ne vois pas par quelle opération du saint esprit il peut deviner
que ce paquet est incompatible.
Pourtant il me dit "un paquet wqebmin version machin incompatiblme a été
trouvé. Ce paquet sera désinstaller, et là j'ai juste <OK>" (dans apt-get
ou synaptic).
Soit tu le précises, soit tu donnes
un autre numéro de version, soit tu le places en hold, soit tu le
pin-point de manière appropriée. Perso, je place les paquets que je
veux pas upgrader en hold, ça me semble le plus simple. Touche "="
dans aptitude.
Et dans apt-get ou dpkg?
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Je ne vois pas par quelle opération du saint esprit il peut deviner que ce paquet est incompatible.
Pourtant il me dit "un paquet wqebmin version machin incompatiblme a été trouvé. Ce paquet sera désinstaller, et là j'ai juste <OK>" (dans apt-get ou synaptic).
Soit tu le précises, soit tu donnes un autre numéro de version, soit tu le places en hold, soit tu le pin-point de manière appropriée. Perso, je place les paquets que je veux pas upgrader en hold, ça me semble le plus simple. Touche "=" dans aptitude.
Et dans apt-get ou dpkg?
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
