Woody rereremis à jour!

Nicolas George <nicolas$george@salle-s.org> wrote:

Oh, surprise, le problème dont tu parles est évoqué, et la solution est
indiquée.

Absolument. Donc je vais sur packages.debian.org et je regarde
comment s'appelle le paquet qui a causé les soucis dont je parlais
chez FreeBSD, le paquet gettext.

Réponse: gettext, gettext-base, gettext-doc, etc.
Je ne vois pas de numéro de version là dedans. Donc si on a le
malheur d'upgrader gettext et de virer du même coup les librairies
partagées de l'ancienne version qui viennent avec, la moitié du
système est en carafe, exactement ce qui s'est passé sous FreeBSD
et exactement le problème qui est décrit dans la FAQ que j'ai citée.

Le fait d'ajouter un numéro de version au nom du paquet, c'est une
solution bien connue que j'avais moi même mentionnée dans mon post.
Le problème est que les gens veulent des noms courts, et veulent virer
les vieilles versions pour se débarrasser du "bloat". Le résultat
est le genre de problème mentionné dans la FAQ.

Après, évidemment, il se peut qu'il y ait des entorses à cette politique.
Mais tu peux considérer ça comme un bug, et le signaler en tant que tel.

Parler de bug dans une telle affaire c'est regarder le problème par
le petit bout de la lorgnette. C'est l'ensemble de l'attitude qui est en
cause, de même que pour l'installeur. Si on veut éviter les conflits
artificiels de ce genre, il ne faut jamais retirer les librairies
partagées anciennes quand on upgrade un paquet, et donc ne pas avoir
peur de laisser le "bloat" s'accumuler.




--

Michel TALON

nicolas vigier wrote:

On 2004-10-31, Mike Massonnet <mykey@sorrynospam.fr> wrote:

Chez Debian, la version stable *EST* fonctionnelle -> Tout fonctionne.

Par contre elle est quand meme assez limitée par les ancienes versions
des logiciels qu'elle propose.

Et c'est dommage de devoir utiliser des logiciels qui ont plus de 2 ans pour
avoir une distribution stable (une distribution ou les mises à jour ne
changent pas les versions de tes logiciels d'un jour à l'autre). Les
autres distributions n'ont pas toutes ce defaut.

2 ans c'est plutot extrême, je dirais deux mois.

--
Registered Linux User #361637 <http://counter.li.org/>
Ma Home-Page: <http://mykey57.free.fr/>
Email: (sur mon site)

OoO Pendant le temps de midi du mardi 02 novembre 2004, vers 12:54,
talon@lpthe.jussieu.fr (Michel Talon) disait:

Réponse: gettext, gettext-base, gettext-doc, etc.
Je ne vois pas de numéro de version là dedans. Donc si on a le
malheur d'upgrader gettext et de virer du même coup les librairies
partagées de l'ancienne version qui viennent avec, la moitié du
système est en carafe, exactement ce qui s'est passé sous FreeBSD
et exactement le problème qui est décrit dans la FAQ que j'ai citée.

Le numéro majeur de gettext n'a pas changé. S'il y a un jour une
librairie gettext en version 2, il y aura un joli paquet Debian
gettext2 ou libgettext2. Pour le moment, ce n'est pas le cas, la brave
librairie conserve la compatibilité ascendante donc tout va bien.

Sans compter que la lib gettext est en statique dans la
libc. J'attends avec impatience l'exemple reproductible sur une
Debian. Mais je ne doute pas que, comme d'habitude, tu parles
totalement en l'air.
--
panic("Aarggh: attempting to free lock with active wait queue - shoot Andy");
2.0.38 /usr/src/linux/fs/locks.c

Vincent Bernat <vincent.bernat@raysa.org> wrote:

OoO Pendant le temps de midi du mardi 02 novembre 2004, vers 12:54,
talon@lpthe.jussieu.fr (Michel Talon) disait:

Réponse: gettext, gettext-base, gettext-doc, etc.
Je ne vois pas de numéro de version là dedans. Donc si on a le
malheur d'upgrader gettext et de virer du même coup les librairies
partagées de l'ancienne version qui viennent avec, la moitié du
système est en carafe, exactement ce qui s'est passé sous FreeBSD
et exactement le problème qui est décrit dans la FAQ que j'ai citée.

Le numéro majeur de gettext n'a pas changé. S'il y a un jour une
librairie gettext en version 2, il y aura un joli paquet Debian
gettext2 ou libgettext2. Pour le moment, ce n'est pas le cas, la brave
librairie conserve la compatibilité ascendante donc tout va bien.

Sans compter que la lib gettext est en statique dans la
libc. J'attends avec impatience l'exemple reproductible sur une
Debian. Mais je ne doute pas que, comme d'habitude, tu parles
totalement en l'air.

Et comme d'habitude tu commences par mordre avant de discuter.
Je n'ai pas dit que la situation s'était produite sur Debian, j'ai dit
qu'elle s'était produite sur FreeBSD et qu'apparemment elle pourrait se
produire de même sur Debian. Donc pour être plus précis, sur
FreeBSD le paquet gettext installe une librairie libintl.so.6
qui se trouve liée à la moitié des softs de la machine. On est passé de
libintl.so.5 à libintl.so.6 sans que personne prenne garde, et
des tas de gens se sont trouvés le bec dans l'eau, quand l'installation
du nouveau gettext a viré libintl.so.5.
Le problème dont on parle ici, ce n'est pas moi qui l'ai inventé,
il est mentionné noir sur blanc dans la FAQ de Debian Testing
qui se trouve sur le site de Debian. Par conséquent je considère que je
ne parle pas en l'air et que tes insultes sont, comme d'habitude,
absolument gratuites.
Je ne prétends pas que cette histoire est arrivée à des utilisateurs de
Debian. Il est fort possible que le "bug" soit repéré bien avant
que le système atteigne l'utilisateur final. Néanmoins, ce genre de bug
nécessite au moins des tas d'efforts (et donc perte de temps et retard)
de la part des développeurs, exactement ce que dit la FAQ.




--

Michel TALON

Benjamin FRANCOIS a écrit:

Michel Talon s'est exprimé en ces termes:

- deux, nul n'est obligé ni d'utiliser Linux 2.4 par les temps qui
courent, ni encore moins alsa quand il utilise Linux 2.4

Ben voyons.

Pourquoi?

<Dans l'école où je bosse>

Les machines pour "utilisateurs finaux" sont en 2.6 depuis un bon moment, et
les seuls noyaux 2.4 qui tournent encore sont sur des serveurs, pour
lesquels la gestion du son est la dernière priorité.

</>

Donc dans les 2 cas, le raisonnement tient la route...

--
Tu as lu les docs. Tu es devenu un informaticien. Que tu le veuilles ou non.
Lire la doc, c'est le Premier et Unique Commandement de l'informaticien.
-+- TP in: Guide du Linuxien pervers - "L'évangile selon St Thomas"

Michel Talon, dans le message <cm7sgs$574$1@asmodee.lpthe.jussieu.fr>, a
écrit :

Réponse: gettext, gettext-base, gettext-doc, etc.
Je ne vois pas de numéro de version là dedans.

Comme dit ailleurs, ce n'est pas pertinent sous GNU/Linux, puisqu'il n'y a
pas de changement de version.

Donc si on a le
malheur d'upgrader gettext et de virer du même coup les librairies
partagées de l'ancienne version qui viennent avec, la moitié du
système est en carafe, exactement ce qui s'est passé sous FreeBSD
et exactement le problème qui est décrit dans la FAQ que j'ai citée.

À ceci près que la manière normale d'installer des packages sous Debian,
c'est d'utiliser dpkg et apt, qui gèrent les dépendances entre paquets. Donc
même si par malheur une upgrade de bibliothèque proposait une version
incompatible (ce qui n'est pas normal, cf. plus bas), la moitié du système
ne serait pas en carafe mais simplement proposée à l'upgrade en même temps
que la bibliothèque.

Parler de bug dans une telle affaire c'est regarder le problème par
le petit bout de la lorgnette.

Non, c'est bel et bien un bug, un bug de packaging, puisque c'est en
contradiction avec la politique de la maison.

Si on veut éviter les conflits
artificiels de ce genre, il ne faut jamais retirer les librairies
partagées anciennes quand on upgrade un paquet, et donc ne pas avoir
peur de laisser le "bloat" s'accumuler.

Mon petit Michel, il faudrait que tu comprennes une bonne fois pour toutes
que tout le monde n'a pas la chance, comme toi, d'avoir des disques durs
infinis (sic).

De toutes façons, comme je l'ai dit, la gestion des dépendances évite les
problèmes. Si tout est installé avec des paquets, il n'y a _rien à faire_,
une bibliothèque que le gestionnaire de package accepte d'enlever est une
bibliothèque qui ne sert pas, nulle part, et ça ne pose aucun problème de
l'enlever.

Les seuls cas où le problème peut se poser sont les cas où un programme a
été installé sans passer par le gestionnaire de packages, en compilant à
partir des sources. Dans ce cas, il me semble raisonnable de supposer que
l'admnistrateur est assez intelligent pour garder les bibliothèques dont il
a besoin.

En bref, tu es en train de projeter sur Debian les faiblesses de la gestion
des packages de FreeBSD, et d'en déduire des problèmes qui n'existent pas.

On Tue, 2 Nov 2004 11:54:04 +0000 (UTC), Michel Talon wrote:

Absolument. Donc je vais sur packages.debian.org et je regarde
comment s'appelle le paquet qui a causé les soucis dont je parlais
chez FreeBSD, le paquet gettext.

Réponse: gettext, gettext-base, gettext-doc, etc.
Je ne vois pas de numéro de version là dedans. Donc si on a le
malheur d'upgrader gettext et de virer du même coup les librairies
partagées de l'ancienne version qui viennent avec, la moitié du
système est en carafe, exactement ce qui s'est passé sous FreeBSD
et exactement le problème qui est décrit dans la FAQ que j'ai citée.

Aucune chance, puisque les bibliothèques partagées qui ont causé
problème sous FreeBSD n'existent pas sous Debian (ça fait partie de la
glibc).

Le fait d'ajouter un numéro de version au nom du paquet, c'est une
solution bien connue que j'avais moi même mentionnée dans mon post.
Le problème est que les gens veulent des noms courts, et veulent virer
les vieilles versions pour se débarrasser du "bloat". Le résultat
est le genre de problème mentionné dans la FAQ.

Je pense que tu as mal compris la FAQ en question. Si un paquet
binaire dépendant de la bibliothèque est installé, on ne peut pas
désinstaller la bibliothèque à cause du système de dépendances ; il faut
soit désinstaller le binaire aussi, soit forcer les dépendances, ce qui
dans les deux cas est une action sciente de l'utilisateur.

Par ailleurs je ne comprends pas ta phrase « le problème est que les
gens veulent des noms courts, et veulent virer les vieilles versions
pour se débarrasser du bloat ». En quoi vouloir des noms courts est-il
un problème ? Y a-t-il un lien causal entre les deux parties de la
phrase ?

Parler de bug dans une telle affaire c'est regarder le problème par
le petit bout de la lorgnette. C'est l'ensemble de l'attitude qui est en
cause, de même que pour l'installeur. Si on veut éviter les conflits
artificiels de ce genre, il ne faut jamais retirer les librairies
partagées anciennes quand on upgrade un paquet, et donc ne pas avoir
peur de laisser le "bloat" s'accumuler.

Puisque les paquets ont des noms différents, les librairies anciennes
ne sont pas supprimées lorsqu'on installe la nouvelle version. Est-ce
que tu as le moindre exemple de ce dont tu parles sous Debian, ou bien
tu ne fais qu'imaginer que Debian a forcément les mêmes problèmes que
FreeBSD ?

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/

Nicolas George <nicolas$george@salle-s.org> wrote:

Michel Talon, dans le message <cm7sgs$574$1@asmodee.lpthe.jussieu.fr>, a

système est en carafe, exactement ce qui s'est passé sous FreeBSD
et exactement le problème qui est décrit dans la FAQ que j'ai citée.

À ceci près que la manière normale d'installer des packages sous Debian,
c'est d'utiliser dpkg et apt, qui gèrent les dépendances entre paquets. Donc
même si par malheur une upgrade de bibliothèque proposait une version
incompatible (ce qui n'est pas normal, cf. plus bas), la moitié du système
ne serait pas en carafe mais simplement proposée à l'upgrade en même temps
que la bibliothèque.

Oui mais le problème tel qu'il est évoqué dans la FAQ, c'est que la
résolution de ce genre de choses est une tâche qui incombe aux
développeurs Debian et prend du temps. Elle explique pourquoi
testing se stabilise lentement.
Donc au lieu de m'expliquer avec condescendance une question qui était
parfaitement expliquée dés mon premier post, tu aurais lu ce que
j'avais écrit du début à la fin, et tu te serais évité de longues
paraphrases.

Mon petit Michel, il faudrait que tu comprennes une bonne fois pour toutes
que tout le monde n'a pas la chance, comme toi, d'avoir des disques durs
infinis (sic).

Si tu achètes les disques aux endroits habituels, tu peux
considérer que tes disques sont infinis, en ce qui concerne
l'installation d'une Debian, même avec 50 versions des librairies.
Autant vouloir avoir une installation maigre est un besoin évident
pour les systèmes embarqués (et celui qui travaille là dedans sait
ce qu'il fait) autant c'est d'une puérilité totale pour le PC de
monsieur tout le monde. Dans un labo comme le notre, les homes
sont maintenant installés sur des systèmes de plusieurs téraoctets,
on n'en voit *jamais* le bout, avec la meilleure volonté du monde.

De toutes façons, comme je l'ai dit, la gestion des dépendances évite les
problèmes. Si tout est installé avec des paquets, il n'y a _rien à faire_,
une bibliothèque que le gestionnaire de package accepte d'enlever est une
bibliothèque qui ne sert pas, nulle part, et ça ne pose aucun problème de
l'enlever.

Relis la FAQ que j'ai citée, et tu verras quel est le problème. Tu veux
installer un nouveau logiciel, il vient avec une nouvelle version de la
librairie qui casse tout si elle enlève l'ancienne. Donc soit tu
renonces à ton soft, soit tu casses tout, dans les deux cas tu n'es
pas heureux.

Les seuls cas où le problème peut se poser sont les cas où un programme a
été installé sans passer par le gestionnaire de packages, en compilant à
partir des sources. Dans ce cas, il me semble raisonnable de supposer que
l'admnistrateur est assez intelligent pour garder les bibliothèques dont il
a besoin.

Ben oui, la moitié des paquets que j'ai installés, j'ai du me taper la
compilation à la main, dont tout KDE et tout Koffice, macsyma, texmacs
qtpython, wxpython, atlas, scipy et bien d'autres, si bien que je tombe
sur le cas de figure que tu évoques. Il n'y a aucune raison de supposer
que tous les logiciels ont été installés à partir du gestionnaire de
paquets, et donc toute suppression sauvage devrait être proscrite.
Comment fait-il l'administrateur intelligent pour garder les librairies
dont il a besoin, des mois ou des années aprés avoir installé ses softs,
au beau milieu d'un apt-get dist upgrade qui modifie quelques centaines
de paquets?

En bref, tu es en train de projeter sur Debian les faiblesses de la gestion
des packages de FreeBSD, et d'en déduire des problèmes qui n'existent pas.

Le principe du gestionnaire de paquets est exactement le même dans les
deux cas et donc les faiblesses sont les mêmes. La différence c'est que
FreeBSD sort 4 releases par an, donc dés fois avec un bon gros bug qui
met la zone, tandis que Debian attend des années que tout se passe bien
et finit par sortir un système complètement périmé. Entre deux maux, je
choisis le moindre, sachant que remettre la librairie libintl.so.5 que
le système t'a violemment sacquée n'est pas plus difficile que d'aller
chercher le paquet gettext d'une vieille release sur un serveur
ftp, extraire la librairie et aller la mettre dans /usr/local/lib.
En fait une petite vérification me montre que j'ai libintl.so.4,
libintl.so.5, et libintl.so.6, ce qui doit me couter 80 KB de "bloat",
quelle catastrophe!

--

Michel TALON

Sam Hocevar <sam+news@zoy.org> wrote:

Par ailleurs je ne comprends pas ta phrase « le problème est que les
gens veulent des noms courts, et veulent virer les vieilles versions
pour se débarrasser du bloat ». En quoi vouloir des noms courts est-il
un problème ? Y a-t-il un lien causal entre les deux parties de la
phrase ?

Nom court implique (dans mon esprit) nom qui ne comprend pas un numéro
de version. Dès lors une seule version de la librairie peut résider dans
le système d'où le problème. On pourrait aussi supprimer de l'ancien
paquet, tout sauf les librairies partagées, ce qui résoudrait le
problème du nom court, mais augmenterait le "bloat".
Sinon je suis d'accord avec toi.

Puisque les paquets ont des noms différents, les librairies anciennes

C'est bien là le problème non?

ne sont pas supprimées lorsqu'on installe la nouvelle version. Est-ce
que tu as le moindre exemple de ce dont tu parles sous Debian, ou bien
tu ne fais qu'imaginer que Debian a forcément les mêmes problèmes que
FreeBSD ?

Enfin, ce problème c'est bien celui que discute la FAQ, je ne l'invente
pas quand même? Je ne te dis pas qu'il n'est pas résolu au cas par cas
par les développeurs Debian pour que ça ne tombe pas sur l'utilisateur
final, mais ça ralentit évidemment la progression des choses de unstable
vers testing et de testing vers stable.

Sam.

--

Michel TALON

On Mon, 1 Nov 2004 14:06:33 +0000 (UTC), Michel Talon wrote:

Package: cdrtools (debian/main).
270060 [ ] cdrtools: GPL or not GPL? The neverending story

En quoi c'est capillotracter que de ne pas vouloir mettre de logiciel
contrefait dans la Debian ?

Si tu ne mets pas les cdrtools dans Debian je te garantis que le nombre
d'installations va tomber à zéro instantanément. Les gens n'ont rien
a faire de vos politicailleries de GPL et consorts, par contre ils ont
envie de graver. Il suffit de voir les réactions dans le camp FreeBSD
où pourtant il existe une alternative fonctionnelle (burncd), tout le
monde veut cdrecord et cdrdao, sans discussion.

Bah oui, et si Schilling ne peut pas être raisonné, une version plus
ancienne (mais libre) ou un fork de cdrtools sera utilisé. C'est pas la
mer à boire.

Package: gsfonts (debian/main).
271427 [ ] gsfonts: Serbian glyphs are wrong (resurrect #250949)

?n quoi c'?st capillotract?r qu? d? vouloir qu? l?s polic?s
s'affich?nt corr?ct?m?nt ? C? n'?st pas r?l?as?-critical d'avoir un
mauvais affichag? comm? c?lui-ci ?

Et bien entendu ça ne sortira pas tant que la traduction en swahili ne
sera pas au point, ainsi qu'en basque pour faire bonne mesure.

http://www.datanation.com/fallacies/falsean.htm

A = affichage des caractères
B = traduction
P = release-critical

Une traduction manquante n'est pas dramatique s'il y a un fallback
en anglais par exemple. En revanche si l'on ne peut même pas lire un
document, c'est beaucoup plus grave.

Package: gstar (debian/main).
252885 [ ] [SX] RM: gstar/woody -- License issues

Désolé, un logiciel qui dit « Redistribution granted for
non-commercial non-profit use only. » n'est non seulement pas libre,
mais ne peut même pas être mis sur un CD vendu.

Pourquoi, il est vendu le CD de Debian?

Oui. Et il est utilisé à des buts commerciaux aussi. Il n'y a pas que
des adolescents et des labos de recherche qui utilisent Debian.

Package: stalin (debian/main).
271836 [ ] [U] FTBFS: source too large

Un package qui ne compile pas, c'est release-critical.

Ben non, il suffit de le virer sans autre perte de temps.

Un bug RC sur un paquet signifie que s'il n'est pas résolu à temps,
on vire le paquet. Et au cas où tu le demanderais, « à temps » ça
signifie à peu de choses près « quand on release ». Et tant qu'il reste
des bugs RC dans les paquets standard et required, on ne release pas, ça
ne sert donc à rien de virer ce paquet secondaire pour l'instant. Mais
rassure-toi, il sera viré pour la release, ou alors le bug sera corrigé.
Exactement la définition d'un bug RC.

Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/