[Linux-bruxelles] erreur très étrange dans gthumb

Jérôme Warnier jwarnier at beeznest.net
Lun 9 Aou 13:26:53 CEST 2004


Le lun 09/08/2004 à 11:34, Frederic Peters a écrit :
> Jérôme Warnier écrivait :
> 
> > > Non seulement Jérôme utilise des numéros de version n'indiquant pas
> > > qu'il ne s'agit pas de paquets officiels mais il semblerait qu'il ne
> > > mette pas systématiquement à jour ce numéro de version lors de
> > > changements.
> > Je commence à en avoir marre qu'on critique sans arrêts. Que ce soit
> 
> Et moi je n'ai pas envie de voir Debian accusée à tort.
Ce en quoi tu as tout-à-fait raison. Et moi non plus.
J'essaye justement de gagner du temps, et d'améliorer la prochaine Stable.
Gagner du temps: il n'est pas possible pour la majorité des utilisateurs
d'utiliser Sid. Il n'est pas possible pour eux non plus d'utiliser Sarge
à cause de quelques très peu nombreux bugs ou retards.
Les packages dont on parle et qu'on appelle "backports" un peu par abus
de langage sont ceux qui sont destinés à Sarge (on ne parle plus ici des
packages GNOME 2.2 pour Woody).
Ils servent à résoudre des problèmes très précis qui me sont pointés par
des utilisateurs immédiats, ou même que je constate moi-même, et qui
ennuient. Il ne s'agit donc ici absolument pas de faire un mix entre
Sarge et Sid pour des raisons de vétusté de packages.
Il y a aussi des packages qui ne sont pas du tout dans Debian
actuellement (DCL, Dokeos, AND 1.2, Exact, COG, Esound 0.2.34, Knoda,
...) et qui ont été placés dans le sous-répertoire "not-debian" pour
bien l'indiquer.

> > clair: ces packages résolvent plein de problèmes (de Sarge), et parfois
> > en créent quelques-uns temporairement, que j'essaye d'ailleurs (avec
> > succès) de régler au plus vite quand on m'apprend qu'il en existe un.
> > Plutôt que de vous plaindre inutilement, vous avez les sources,
> > profitez-en, et soumettez le correctif que vous jugez approprié.
> 
> Le problème présent, c'est que Stan ne savait même pas que son paquet
> ne provenait pas de Debian.  C'est ça qui m'ennuie.
Oui, il ne savait pas utiliser apt-cache policy, il a appris, et s'est
même excusé ;-)

> > Vous l'utilisez si vous jugez que c'est utile, je n'y force personne,
> > mais qu'on arrête de se plaindre sans proposer de solution.
> 
> Ma solution, c'est ce que je pensais que tu faisais, ajouter quelque
> chose dans le numéro de version, pour indiquer qu'il ne s'agit pas ici
> d'un paquet Debian.
Je le faisais, effectivement, pour les vrais backports GNOME 2.2 pour
Woody, parce que Woody était Stable, et que donc c'était différent
(difficile à expliquer en quoi). Le fait de garder la même version
permet "d'upgrader" à la version officielle dès qu'elle arrive dans
Testing et de savoir facilement de quelle version exacte on parle
(comparaison avec Sid, par exemple).

> > Dans le cas de gthumb plus particulièrement, c'est le package original
> > qui déconne (je suspecte qu'il n'aimait pas les versions
> 
> Le paquet original peut très bien déconner mais comme le problème
> n'est pas présent dans sarge et déjà corrigé dans sid, ça passe
> inaperçu.
Non, le *package* n'est pas présent/fonctionnel dans Sarge. Ça n'est pas
plus foireux qu'une Sarge, seulement différemment. ;-)

> > d'autoconf/automake). D'ailleurs, il semblerait que la version suivante
> > dans Debian règle ce problème, qui devait probablement aussi exister
> > dans Sid.
> 
> Qui a existé, qui a été corrigé, oui.  Par un fabuleux hasard, je n'ai
> pas eu à utiliser gthumb quand c'était cassé et ne me suis rendu
> compte de rien.
Ben apparemment, ça ne fonctionne pas beaucoup mieux avec le -3.

> > Si je n'ai pas changé le n° de version, c'est parce que je me suis rendu
> > compte très vite du problème, et j'ai tenté immédiatement plusieurs
> > façons de régler le pb, apparemment sans succès, et donc sans aucune
> > raison d'augmenter le n° de version pour forcer l'installation (et le
> > download) chez les gens alors que cela ne changeait rien. Ensuite, je
> > suis parti loin de mon ordinateur pendant plusieurs jours, et donc le
> > problème n'a pas été résolu. Est-ce vraiment si grave?
> 
> Tu laisses un paquet qui ne fonctionne pas dans ton archive.  Tu
> aurais pu le taper de côté le temps de résoudre le problème, non ?
Oui, j'aurais pu. Mais encore une fois, le package gthumb dans Sarge ne
fonctionne pas du tout.

> Tes backports se révèlent utiles à certains, c'est super.  Pour ma
> part, je n'aime pas m'éloigner d'une Debian officielle, c'est mon
> affaire.
Ben oui, ceux qui utilisent apt.bxlug.be devraient en être conscients.
Et d'habitude c'est le cas.

En fait, ce qui t'ennuies surtout, c'est que les gens pourraient
soumettre des bugreports dans Debian sans avoir vérifié que ça pouvait
être dû à la provenance des packages.
Dès lors, pourquoi reportbug ne vérifierait-il pas cela? Le problème
n'existe pas que sur le "mirror" ou chez les utilisateurs du BxLUG.
Corriger le "problème" ici est une solution locale, mais pas suffisante.

> Le seul truc que je demande, c'est que la version du paquet reflète le
> fait qu'il ne s'agit pas d'un paquet officiel.
Pour moi, l'endroit où on l'a trouvé suffit amplement.

Maintenant, si on voulait utiliser une numérotation spécifique, quelle
convention utiliser?
Il faut évidemment que notre n° soit toujours légèrement inférieur à
celui officiel du package dans Debian, pour que les upgrades se fassent
naturellement.
Je propose donc de retrancher le n° de version du package de 1, et de le
"suffixer" de "bxl" suivi lui-même d'un n° de révision du package chez
nous.
Ça donnerait:
version Debian: 1.2.3-3
version BxLUG: 1.2.3-2bxl1, puis 1.2.3-2bxl2, ...

Qu'en pensez-vous?

>         Frédéric
-- 
Jérôme Warnier
Consultant
BeezNest
http://beeznest.net





Plus d'informations sur la liste de diffusion Linux-bruxelles