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! =-----
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les dépendances. Tu installes un programme, il installe les dépendances. Mais si tu désinstalles et que d'autres programmes installés depuis ont besoin des mêmes dépendances, est qu'il va attendre que le dernier programme soit désinstallé avec de désinstaller les dépendances?
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:
(snip)
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans
problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les
dépendances. Tu installes un programme, il installe les dépendances.
Mais si tu désinstalles et que d'autres programmes installés depuis
ont besoin des mêmes dépendances, est qu'il va attendre que le dernier
programme soit désinstallé avec de désinstaller les dépendances?
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! =-----
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les dépendances. Tu installes un programme, il installe les dépendances. Mais si tu désinstalles et que d'autres programmes installés depuis ont besoin des mêmes dépendances, est qu'il va attendre que le dernier programme soit désinstallé avec de désinstaller les dépendances?
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! =-----
Vincent Bernat
OoO Pendant le temps de midi du mardi 09 décembre 2003, vers 12:44, GP disait:
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les dépendances. Tu installes un programme, il installe les dépendances. Mais si tu désinstalles et que d'autres programmes installés depuis ont besoin des mêmes dépendances, est qu'il va attendre que le dernier programme soit désinstallé avec de désinstaller les dépendances?
swaret ne gère que les installs. -- printk("Penguin %d is stuck in the bottle.n", i); 2.0.38 /usr/src/linux/arch/sparc/kernel/smp.c
OoO Pendant le temps de midi du mardi 09 décembre 2003, vers 12:44, GP
<gilpel@inverse.nretla.org> disait:
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans
problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les
dépendances. Tu installes un programme, il installe les
dépendances. Mais si tu désinstalles et que d'autres programmes
installés depuis ont besoin des mêmes dépendances, est qu'il va
attendre que le dernier programme soit désinstallé avec de
désinstaller les dépendances?
swaret ne gère que les installs.
--
printk("Penguin %d is stuck in the bottle.n", i);
2.0.38 /usr/src/linux/arch/sparc/kernel/smp.c
OoO Pendant le temps de midi du mardi 09 décembre 2003, vers 12:44, GP disait:
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les dépendances. Tu installes un programme, il installe les dépendances. Mais si tu désinstalles et que d'autres programmes installés depuis ont besoin des mêmes dépendances, est qu'il va attendre que le dernier programme soit désinstallé avec de désinstaller les dépendances?
swaret ne gère que les installs. -- printk("Penguin %d is stuck in the bottle.n", i); 2.0.38 /usr/src/linux/arch/sparc/kernel/smp.c
GP
Vincent Bernat wrote:
OoO Pendant le temps de midi du mardi 09 décembre 2003, vers 12:44, GP disait:
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les dépendances. Tu installes un programme, il installe les dépendances. Mais si tu désinstalles et que d'autres programmes installés depuis ont besoin des mêmes dépendances, est qu'il va attendre que le dernier programme soit désinstallé avec de désinstaller les dépendances?
swaret ne gère que les installs.
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à?
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/
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret ou slapt-get en même temps? Alors, peut-on dire que la différence entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
J'espère que je ne dis pas trop de bêtises là. La journée a été longue et je suis plus mort que vivant.
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! =-----
Vincent Bernat wrote:
OoO Pendant le temps de midi du mardi 09 décembre 2003, vers 12:44, GP
<gilpel@inverse.nretla.org> disait:
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans
problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les
dépendances. Tu installes un programme, il installe les
dépendances. Mais si tu désinstalles et que d'autres programmes
installés depuis ont besoin des mêmes dépendances, est qu'il va
attendre que le dernier programme soit désinstallé avec de
désinstaller les dépendances?
swaret ne gère que les installs.
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à?
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/
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret
ou slapt-get en même temps? Alors, peut-on dire que la différence
entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
J'espère que je ne dis pas trop de bêtises là. La journée a été longue
et je suis plus mort que vivant.
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! =-----
OoO Pendant le temps de midi du mardi 09 décembre 2003, vers 12:44, GP disait:
Dans la pratique, 99% de ces fichiers peuvent être poubellisés sans problème...
Bon! Allons-y pour une question piège. On dit que swaret gère les dépendances. Tu installes un programme, il installe les dépendances. Mais si tu désinstalles et que d'autres programmes installés depuis ont besoin des mêmes dépendances, est qu'il va attendre que le dernier programme soit désinstallé avec de désinstaller les dépendances?
swaret ne gère que les installs.
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à?
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/
Et, évidemment, il n'y a pas moyen d'employer checkinstall et swaret ou slapt-get en même temps? Alors, peut-on dire que la différence entre ces deux utlitaires et apt-get, c'est que apt-get désinstalle?
J'espère que je ne dis pas trop de bêtises là. La journée a été longue et je suis plus mort que vivant.
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! =-----
talon
GP wrote:
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à?
Je ne veux pas m'immiscer dans le débat mais ne pas virer les dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait toute l'utilisabilité d'un système comme celui de FreeBSD et la merdicité d'un système à dépendances strictes comme Debian. La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse. Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle. Virer automatiquement la vieille est d'une débilité monstrueuse. Là encore ça pouvait se concevoir quand les disques faisaient 1 GB. Maintenant c'est ridicule.
Evidemment si les développeurs modifient l'interface de la librairie sans incrémenter le numéro de série, c'est sur on va avoir un gros problème. Ce problème doit se résoudre en intervenant sur la librairie spécifique et non pas en cassant toute la compatibilité des logiciels qu'on a pu installer sur la machine gratuitement.
--
Michel TALON
GP <gilpel@inverse.nretla.org> wrote:
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à?
Je ne veux pas m'immiscer dans le débat mais ne pas virer les
dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait
toute l'utilisabilité d'un système comme celui de FreeBSD et la
merdicité d'un système à dépendances strictes comme Debian. La première
fois que j'ai fait
apt-get install postfix
et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est
d'une connerie monstrueuse. Il existe dans les Unix modernes un système
de versions sur les librairies partagées qui permet à une vieille
librairie de coexister avec une nouvelle. Virer automatiquement la
vieille est d'une débilité monstrueuse. Là encore ça pouvait se
concevoir quand les disques faisaient 1 GB. Maintenant c'est ridicule.
Evidemment si les développeurs modifient l'interface de la librairie
sans incrémenter le numéro de série, c'est sur on va avoir un gros
problème. Ce problème doit se résoudre en intervenant sur la librairie
spécifique et non pas en cassant toute la compatibilité des logiciels
qu'on a pu installer sur la machine gratuitement.
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à?
Je ne veux pas m'immiscer dans le débat mais ne pas virer les dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait toute l'utilisabilité d'un système comme celui de FreeBSD et la merdicité d'un système à dépendances strictes comme Debian. La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse. Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle. Virer automatiquement la vieille est d'une débilité monstrueuse. Là encore ça pouvait se concevoir quand les disques faisaient 1 GB. Maintenant c'est ridicule.
Evidemment si les développeurs modifient l'interface de la librairie sans incrémenter le numéro de série, c'est sur on va avoir un gros problème. Ce problème doit se résoudre en intervenant sur la librairie spécifique et non pas en cassant toute la compatibilité des logiciels qu'on a pu installer sur la machine gratuitement.
--
Michel TALON
Sam Hocevar
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote:
Je ne veux pas m'immiscer dans le débat mais ne pas virer les dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait toute l'utilisabilité d'un système comme celui de FreeBSD et la merdicité d'un système à dépendances strictes comme Debian. La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse.
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 ?
Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle. Virer automatiquement la vieille est d'une débilité monstrueuse.
Je ne sais pas de qui tu fais le procès, mais sous Debian des versions majeures d'une même librairie coexistent parfaitement. Et je pense que c'est le cas sur n'importe quelle distribution.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote:
Je ne veux pas m'immiscer dans le débat mais ne pas virer les
dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait
toute l'utilisabilité d'un système comme celui de FreeBSD et la
merdicité d'un système à dépendances strictes comme Debian. La première
fois que j'ai fait
apt-get install postfix
et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est
d'une connerie monstrueuse.
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 ?
Il existe dans les Unix modernes un système de versions sur les
librairies partagées qui permet à une vieille librairie de coexister
avec une nouvelle. Virer automatiquement la vieille est d'une débilité
monstrueuse.
Je ne sais pas de qui tu fais le procès, mais sous Debian des
versions majeures d'une même librairie coexistent parfaitement. Et je
pense que c'est le cas sur n'importe quelle distribution.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote:
Je ne veux pas m'immiscer dans le débat mais ne pas virer les dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait toute l'utilisabilité d'un système comme celui de FreeBSD et la merdicité d'un système à dépendances strictes comme Debian. La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse.
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 ?
Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle. Virer automatiquement la vieille est d'une débilité monstrueuse.
Je ne sais pas de qui tu fais le procès, mais sous Debian des versions majeures d'une même librairie coexistent parfaitement. Et je pense que c'est le cas sur n'importe quelle distribution.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
george
Michel Talon, dans le message <br6muf$tcd$, a écrit :
La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial.
Déjà, tu es un peu à côté de la plaque. Il était question de « remove foobar » qui enlève aussi les dépendances installées lors de l'installations foobar. Là, tu parles des incompatibilités entre packages.
Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle.
(C'est bibliothèque, pas librairie.)
Oui, et de fait, c'est utilisé. Qu moins dans le cas de Debian, qui est celui que je connais le mieux, tu peux parfaitement avoir plusieurs versions de la même bibliothèque qui coexistent. J'ai par exemple ici une libXaw.so.6 et une libXaw.so.7, aucun problème. C'est prévu pour.
Les incompatibilités, c'est quelque chose de beaucoup plus particulier : ça veut vraiment dire qu'un package ne peut pas coexister avec un autre. Dans le cas de Postfix/exim, il y a comme le signale Sam la propriété de /usr/lib/sendmail, de /etc/aliases. Il y a aussi le conflit sur le port TCP/25. Il est vrai que les fichiers eux-mêmes ne sont pas en conflit, et qu'il est légitime, même si un peu baroque, de vouloir avoir les binaires de Postfix et ceux d'exim. Ça pourrait se résoudre en coupant le package en deux : postfix pour le logiciel lui-même, sans aucun conflit, et postfix-mta pour ce qui en fait le MTA de la machine, en conflit avec les autres *-mta. Mais est-ce vraiment la peine.
Cependant, je vois un exemple encore plus marquant de conflits : les *-dev. J'ai deux libXaw, disais-je, mais le /usr/X11R6/include/X11/Xaw qui va avec, j'en fais quoi ? Ici, c'est bien les mêmes fichiers, et les installer à un endroit non-standard ne conduira qu'à des contorsions abominables pour compiler (j'en sais quelque chose, on passe notre temps à ça ici quand on installe des trucs en tant que non-root). Et pour le coup, si tu peux avoir besoin de la libXaw.so.6, on se demande un peu ce que tu ferais avec les vieux include. Je note au passage que cette histoire de conflits entre les entêtes mais pas entre les binaires est un argument en faveur du découpage en foo et foo-dev (réveillons les vieux trolls).
Evidemment si les développeurs modifient l'interface de la librairie sans incrémenter le numéro de série, c'est sur on va avoir un gros problème
Non, il n'y a pas de problème : le SONAME est de la responsabilité de la distribution. Celui mis par le makefile par défaut n'est qu'indicatif. Il ne peut pas prendre en compte, par exemple, le changement de version d'une dépendance.
Michel Talon, dans le message <br6muf$tcd$1@asmodee.lpthe.jussieu.fr>, a
écrit :
La première
fois que j'ai fait
apt-get install postfix
et que ça m'a viré exim j'ai trouvé ça génial.
Déjà, tu es un peu à côté de la plaque. Il était question de « remove
foobar » qui enlève aussi les dépendances installées lors de
l'installations foobar. Là, tu parles des incompatibilités entre
packages.
Il existe dans les Unix modernes un système
de versions sur les librairies partagées qui permet à une vieille
librairie de coexister avec une nouvelle.
(C'est bibliothèque, pas librairie.)
Oui, et de fait, c'est utilisé. Qu moins dans le cas de Debian, qui est
celui que je connais le mieux, tu peux parfaitement avoir plusieurs
versions de la même bibliothèque qui coexistent. J'ai par exemple ici
une libXaw.so.6 et une libXaw.so.7, aucun problème. C'est prévu pour.
Les incompatibilités, c'est quelque chose de beaucoup plus particulier :
ça veut vraiment dire qu'un package ne peut pas coexister avec un autre.
Dans le cas de Postfix/exim, il y a comme le signale Sam la propriété de
/usr/lib/sendmail, de /etc/aliases. Il y a aussi le conflit sur le port
TCP/25. Il est vrai que les fichiers eux-mêmes ne sont pas en conflit,
et qu'il est légitime, même si un peu baroque, de vouloir avoir les
binaires de Postfix et ceux d'exim. Ça pourrait se résoudre en coupant
le package en deux : postfix pour le logiciel lui-même, sans aucun
conflit, et postfix-mta pour ce qui en fait le MTA de la machine, en
conflit avec les autres *-mta. Mais est-ce vraiment la peine.
Cependant, je vois un exemple encore plus marquant de conflits : les
*-dev. J'ai deux libXaw, disais-je, mais le /usr/X11R6/include/X11/Xaw
qui va avec, j'en fais quoi ? Ici, c'est bien les mêmes fichiers, et les
installer à un endroit non-standard ne conduira qu'à des contorsions
abominables pour compiler (j'en sais quelque chose, on passe notre temps
à ça ici quand on installe des trucs en tant que non-root). Et pour le
coup, si tu peux avoir besoin de la libXaw.so.6, on se demande un peu ce
que tu ferais avec les vieux include. Je note au passage que cette
histoire de conflits entre les entêtes mais pas entre les binaires est
un argument en faveur du découpage en foo et foo-dev (réveillons les
vieux trolls).
Evidemment si les développeurs modifient l'interface de la librairie
sans incrémenter le numéro de série, c'est sur on va avoir un gros
problème
Non, il n'y a pas de problème : le SONAME est de la responsabilité de la
distribution. Celui mis par le makefile par défaut n'est qu'indicatif.
Il ne peut pas prendre en compte, par exemple, le changement de version
d'une dépendance.
Michel Talon, dans le message <br6muf$tcd$, a écrit :
La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial.
Déjà, tu es un peu à côté de la plaque. Il était question de « remove foobar » qui enlève aussi les dépendances installées lors de l'installations foobar. Là, tu parles des incompatibilités entre packages.
Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle.
(C'est bibliothèque, pas librairie.)
Oui, et de fait, c'est utilisé. Qu moins dans le cas de Debian, qui est celui que je connais le mieux, tu peux parfaitement avoir plusieurs versions de la même bibliothèque qui coexistent. J'ai par exemple ici une libXaw.so.6 et une libXaw.so.7, aucun problème. C'est prévu pour.
Les incompatibilités, c'est quelque chose de beaucoup plus particulier : ça veut vraiment dire qu'un package ne peut pas coexister avec un autre. Dans le cas de Postfix/exim, il y a comme le signale Sam la propriété de /usr/lib/sendmail, de /etc/aliases. Il y a aussi le conflit sur le port TCP/25. Il est vrai que les fichiers eux-mêmes ne sont pas en conflit, et qu'il est légitime, même si un peu baroque, de vouloir avoir les binaires de Postfix et ceux d'exim. Ça pourrait se résoudre en coupant le package en deux : postfix pour le logiciel lui-même, sans aucun conflit, et postfix-mta pour ce qui en fait le MTA de la machine, en conflit avec les autres *-mta. Mais est-ce vraiment la peine.
Cependant, je vois un exemple encore plus marquant de conflits : les *-dev. J'ai deux libXaw, disais-je, mais le /usr/X11R6/include/X11/Xaw qui va avec, j'en fais quoi ? Ici, c'est bien les mêmes fichiers, et les installer à un endroit non-standard ne conduira qu'à des contorsions abominables pour compiler (j'en sais quelque chose, on passe notre temps à ça ici quand on installe des trucs en tant que non-root). Et pour le coup, si tu peux avoir besoin de la libXaw.so.6, on se demande un peu ce que tu ferais avec les vieux include. Je note au passage que cette histoire de conflits entre les entêtes mais pas entre les binaires est un argument en faveur du découpage en foo et foo-dev (réveillons les vieux trolls).
Evidemment si les développeurs modifient l'interface de la librairie sans incrémenter le numéro de série, c'est sur on va avoir un gros problème
Non, il n'y a pas de problème : le SONAME est de la responsabilité de la distribution. Celui mis par le makefile par défaut n'est qu'indicatif. Il ne peut pas prendre en compte, par exemple, le changement de version d'une dépendance.
Sam Hocevar
On Wed, 10 Dec 2003 12:13:58 +0000 (UTC), Nicolas George wrote:
Non, il n'y a pas de problème : le SONAME est de la responsabilité de la distribution. Celui mis par le makefile par défaut n'est qu'indicatif.
Je ne suis pas vraiment d'accord ; le SONAME est de la responsabilité de l'auteur de la lib, et les distributions, si elles veulent assurer la compatibilité binaire entre elles, doivent s'aligner sur les numéros majeurs d'upstream et pas les inventer.
Lorsque l'auteur ne fournit pas de SONAME (la plupart du temps parce que l'API ou l'ABI ne sont pas stables), il n'est pas recommandé d'en créer un de zéro, mais plutôt de lier les binaires en statique, ou d'attendre la stabilisation de l'interface. C'est par exemple le cas pour XFree86 dont libXv, libXinerama etc. n'existent qu'en version statique.
Il y a parfoit de gros problèmes de compréhension d'upstream : par exemple les auteurs de libpng ont mis très longtemps à comprendre que même si l'API ne changeait pas entre deux versions, un changement d'ABI nécessitait l'incrémentation du numéro majeur.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
On Wed, 10 Dec 2003 12:13:58 +0000 (UTC), Nicolas George wrote:
Non, il n'y a pas de problème : le SONAME est de la responsabilité de la
distribution. Celui mis par le makefile par défaut n'est qu'indicatif.
Je ne suis pas vraiment d'accord ; le SONAME est de la responsabilité
de l'auteur de la lib, et les distributions, si elles veulent assurer la
compatibilité binaire entre elles, doivent s'aligner sur les numéros
majeurs d'upstream et pas les inventer.
Lorsque l'auteur ne fournit pas de SONAME (la plupart du temps parce
que l'API ou l'ABI ne sont pas stables), il n'est pas recommandé d'en
créer un de zéro, mais plutôt de lier les binaires en statique, ou
d'attendre la stabilisation de l'interface. C'est par exemple le cas
pour XFree86 dont libXv, libXinerama etc. n'existent qu'en version
statique.
Il y a parfoit de gros problèmes de compréhension d'upstream : par
exemple les auteurs de libpng ont mis très longtemps à comprendre que
même si l'API ne changeait pas entre deux versions, un changement d'ABI
nécessitait l'incrémentation du numéro majeur.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Wed, 10 Dec 2003 12:13:58 +0000 (UTC), Nicolas George wrote:
Non, il n'y a pas de problème : le SONAME est de la responsabilité de la distribution. Celui mis par le makefile par défaut n'est qu'indicatif.
Je ne suis pas vraiment d'accord ; le SONAME est de la responsabilité de l'auteur de la lib, et les distributions, si elles veulent assurer la compatibilité binaire entre elles, doivent s'aligner sur les numéros majeurs d'upstream et pas les inventer.
Lorsque l'auteur ne fournit pas de SONAME (la plupart du temps parce que l'API ou l'ABI ne sont pas stables), il n'est pas recommandé d'en créer un de zéro, mais plutôt de lier les binaires en statique, ou d'attendre la stabilisation de l'interface. C'est par exemple le cas pour XFree86 dont libXv, libXinerama etc. n'existent qu'en version statique.
Il y a parfoit de gros problèmes de compréhension d'upstream : par exemple les auteurs de libpng ont mis très longtemps à comprendre que même si l'API ne changeait pas entre deux versions, un changement d'ABI nécessitait l'incrémentation du numéro majeur.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
talon
Sam Hocevar <sam+ wrote:
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote:
Je ne veux pas m'immiscer dans le débat mais ne pas virer les dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait toute l'utilisabilité d'un système comme celui de FreeBSD et la merdicité d'un système à dépendances strictes comme Debian. La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse.
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. 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. Au moins il faudrait un flag pour dire qu'on souhaite se débarrasser de l'ancienne version.
Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle. Virer automatiquement la vieille est d'une débilité monstrueuse.
Je ne sais pas de qui tu fais le procès, mais sous Debian des versions majeures d'une même librairie coexistent parfaitement. Et je pense que c'est le cas sur n'importe quelle distribution.
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. 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.
Sam.
--
Michel TALON
Sam Hocevar <sam+news@zoy.org> wrote:
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote:
Je ne veux pas m'immiscer dans le débat mais ne pas virer les
dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait
toute l'utilisabilité d'un système comme celui de FreeBSD et la
merdicité d'un système à dépendances strictes comme Debian. La première
fois que j'ai fait
apt-get install postfix
et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est
d'une connerie monstrueuse.
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. 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. Au moins
il faudrait un flag pour dire qu'on souhaite se débarrasser de
l'ancienne version.
Il existe dans les Unix modernes un système de versions sur les
librairies partagées qui permet à une vieille librairie de coexister
avec une nouvelle. Virer automatiquement la vieille est d'une débilité
monstrueuse.
Je ne sais pas de qui tu fais le procès, mais sous Debian des
versions majeures d'une même librairie coexistent parfaitement. Et je
pense que c'est le cas sur n'importe quelle distribution.
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. 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 08:53:35 +0000 (UTC), Michel Talon wrote:
Je ne veux pas m'immiscer dans le débat mais ne pas virer les dépendances, c'est à mon avis une *excellente* idée. C'est ce qui fait toute l'utilisabilité d'un système comme celui de FreeBSD et la merdicité d'un système à dépendances strictes comme Debian. La première fois que j'ai fait apt-get install postfix et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse.
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. 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. Au moins il faudrait un flag pour dire qu'on souhaite se débarrasser de l'ancienne version.
Il existe dans les Unix modernes un système de versions sur les librairies partagées qui permet à une vieille librairie de coexister avec une nouvelle. Virer automatiquement la vieille est d'une débilité monstrueuse.
Je ne sais pas de qui tu fais le procès, mais sous Debian des versions majeures d'une même librairie coexistent parfaitement. Et je pense que c'est le cas sur n'importe quelle distribution.
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. 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.
Sam.
--
Michel TALON
george
Sam Hocevar , dans le message <slrnbte5pv.3ld.sam+, a écrit :
Je ne suis pas vraiment d'accord ; le SONAME est de la responsabilité de l'auteur de la lib, et les distributions, si elles veulent assurer la compatibilité binaire entre elles, doivent s'aligner sur les numéros majeurs d'upstream et pas les inventer.
Je pense que tu n'as pas vu certaines subtilités. Prenons un cas imaginaire mais précis. Je suis l'auteur d'une bibliothèque, appelons-la libfoo. Son interface, API comme ABI est parfaitement fixée. le makefile par défaut donne libfoo.so.1 comme SONAME, tout va bien.
C'est une bibliothèque moderne, elle gère l'internationalisation. Et pour ce faire, bien entendu, elle se sert de l'interface standard pour ça : wchar_t.
Soit maintenant un OS de type Unix, disons BarOS, qui en est à la version 1.42. Je n'ai jamais entendu parler de BarOS, mais comme je programme en suivant scrupuleusement la Single Unix Specification, libfoo compile comme une fleur dessus. Ils décident de l'include dans leur distribution. Les wchar_t de BarOS 1.x dont 16 bits, la libc s'appelle libc.so.1.
Vient la version 2.0 de BarOS, avec, entre autres nouveautés, des wchar_t de 32 bits. La libc s'appelle maintenant libs.so.2, et l'ancienne est fournie à titre de compatibilité, ainsi que toutes les bibliothèques.
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. 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.
Ça te semble tiré par les cheveux ? Remplace BarOS par FreeBSD : la libc change de SONAME à chaque release majeure.
Bien sûr, le développeur doit fournir un SONAME par défaut convenable, qui change à chaque fois que l'interface binaire change, et qui constitue une base de travail raisonnable. Mais ce SONAME par défaut ne peut pas tenir compte des évolutions incompatibles des dépendances, ça seul celui qui distribue la bibliothèque packagée pour un certain OS peut le faire.
Sam Hocevar , dans le message <slrnbte5pv.3ld.sam+news@poulet.zoy.org>,
a écrit :
Je ne suis pas vraiment d'accord ; le SONAME est de la responsabilité
de l'auteur de la lib, et les distributions, si elles veulent assurer la
compatibilité binaire entre elles, doivent s'aligner sur les numéros
majeurs d'upstream et pas les inventer.
Je pense que tu n'as pas vu certaines subtilités. Prenons un cas
imaginaire mais précis. Je suis l'auteur d'une bibliothèque, appelons-la
libfoo. Son interface, API comme ABI est parfaitement fixée. le makefile
par défaut donne libfoo.so.1 comme SONAME, tout va bien.
C'est une bibliothèque moderne, elle gère l'internationalisation. Et
pour ce faire, bien entendu, elle se sert de l'interface standard pour
ça : wchar_t.
Soit maintenant un OS de type Unix, disons BarOS, qui en est à la
version 1.42. Je n'ai jamais entendu parler de BarOS, mais comme je
programme en suivant scrupuleusement la Single Unix Specification,
libfoo compile comme une fleur dessus. Ils décident de l'include dans
leur distribution. Les wchar_t de BarOS 1.x dont 16 bits, la libc
s'appelle libc.so.1.
Vient la version 2.0 de BarOS, avec, entre autres nouveautés, des
wchar_t de 32 bits. La libc s'appelle maintenant libs.so.2, et
l'ancienne est fournie à titre de compatibilité, ainsi que toutes les
bibliothèques.
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.
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.
Ça te semble tiré par les cheveux ? Remplace BarOS par FreeBSD : la
libc change de SONAME à chaque release majeure.
Bien sûr, le développeur doit fournir un SONAME par défaut convenable,
qui change à chaque fois que l'interface binaire change, et qui
constitue une base de travail raisonnable. Mais ce SONAME par défaut ne
peut pas tenir compte des évolutions incompatibles des dépendances, ça
seul celui qui distribue la bibliothèque packagée pour un certain OS
peut le faire.
Sam Hocevar , dans le message <slrnbte5pv.3ld.sam+, a écrit :
Je ne suis pas vraiment d'accord ; le SONAME est de la responsabilité de l'auteur de la lib, et les distributions, si elles veulent assurer la compatibilité binaire entre elles, doivent s'aligner sur les numéros majeurs d'upstream et pas les inventer.
Je pense que tu n'as pas vu certaines subtilités. Prenons un cas imaginaire mais précis. Je suis l'auteur d'une bibliothèque, appelons-la libfoo. Son interface, API comme ABI est parfaitement fixée. le makefile par défaut donne libfoo.so.1 comme SONAME, tout va bien.
C'est une bibliothèque moderne, elle gère l'internationalisation. Et pour ce faire, bien entendu, elle se sert de l'interface standard pour ça : wchar_t.
Soit maintenant un OS de type Unix, disons BarOS, qui en est à la version 1.42. Je n'ai jamais entendu parler de BarOS, mais comme je programme en suivant scrupuleusement la Single Unix Specification, libfoo compile comme une fleur dessus. Ils décident de l'include dans leur distribution. Les wchar_t de BarOS 1.x dont 16 bits, la libc s'appelle libc.so.1.
Vient la version 2.0 de BarOS, avec, entre autres nouveautés, des wchar_t de 32 bits. La libc s'appelle maintenant libs.so.2, et l'ancienne est fournie à titre de compatibilité, ainsi que toutes les bibliothèques.
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. 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.
Ça te semble tiré par les cheveux ? Remplace BarOS par FreeBSD : la libc change de SONAME à chaque release majeure.
Bien sûr, le développeur doit fournir un SONAME par défaut convenable, qui change à chaque fois que l'interface binaire change, et qui constitue une base de travail raisonnable. Mais ce SONAME par défaut ne peut pas tenir compte des évolutions incompatibles des dépendances, ça seul celui qui distribue la bibliothèque packagée pour un certain OS peut le faire.
Sebastien Tanguy
Sam Hocevar <sam+ writes:
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote: [...]
et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse.
Si tu gardes postfix et exim, sur quoi pointe /usr/sbin/sendmail ? Et /usr/bin/newaliases ?
update-alternatives ? J'ai bon ?
seb. -- ``Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)'' --- Linus Torvalds
Sam Hocevar <sam+news@zoy.org> writes:
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote:
[...]
et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est
d'une connerie monstrueuse.
Si tu gardes postfix et exim, sur quoi pointe /usr/sbin/sendmail ?
Et /usr/bin/newaliases ?
update-alternatives ? J'ai bon ?
seb.
--
``Only wimps use tape backup: _real_ men just upload their important
stuff on ftp, and let the rest of the world mirror it ;)''
--- Linus Torvalds
On Wed, 10 Dec 2003 08:53:35 +0000 (UTC), Michel Talon wrote: [...]
et que ça m'a viré exim j'ai trouvé ça génial. A la réflexion c'est d'une connerie monstrueuse.
Si tu gardes postfix et exim, sur quoi pointe /usr/sbin/sendmail ? Et /usr/bin/newaliases ?
update-alternatives ? J'ai bon ?
seb. -- ``Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)'' --- Linus Torvalds
