[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Suivre un script pas à pas - Debconf et Webcalendar



Jean-Yves F. Barbier a écrit :
> Guillaume Yziquel wrote:
>>
>> Ma session bashd est reproduite plus bas. J'ai pas vraiment compris
>> comment rentrer dans le fichier sourcé
>>
>>> . /usr/share/debconf/confmodule
> 
> là, j'aurais du mal à t'aider parce que je viens de me rendre compte que
> les scripts d'appel (.preinst, .prerm, etc) sont en bash, mais que ceux de
> Debian sont en Perl, ça ne facilite pas la chose et je suis Tloin d'être un
> spécialiste de Perl

Le scripts .prerm sont en Perl dans Debian? Pour ma part, je ny vois que
du shell.

>> et j'ai pas bien compris si la bête qui renvoie le code d'erreur 10 est
>> /usr/share/debconf/confmodule ou bien une autre bête comme
>> /usr/share/dbconfig-common/dpkg/prerm.
> 
> difficile: je n'ai aucun DIR .../dbconfig-common en sid (ln#6)
> [Tiens, et d'ailleurs pas en Etch non plus !!!]

Je crois que dbconfig est quelque chose qui a trait à la configuration
de bases de données. webcalendar utilise des bases de données, et
utilise donc dbconfig-common.

	http://packages.debian.org/unstable/admin/dbconfig-common

> mais le code d'erreur vient toujours du dernier exécuté; donc soit c'est
> lui qui a un PB, soit les résultats (passage de parms, ou récup' de
> variables d'environnement) qu'il a reçu sont erronées

Donc à priori, c'est l'appel à debconf/confmodule qui merdouille.

> Si mes souvenirs sont bons, '@' représente une liste d'arguments; donc
> /usr/share/debconf/confmodule campe le tableau en préparant les variables,
> reste à savoir ce que fait le 2nd (ln#6); et en dernier vient un appel
> (dbc_go webcalendar) qui, logiquement, devrait correspondre à une
> extraction de la base de données des noms de fichiers à supprimer.

J'aimerais bien pouvoir suivre ce script... au sein de ma session bashdb.

> Donc l'erreur est retournée pas cette fonction, donc, comme on ne peut pas
> la suspecter de merdouiller, c'est qu'elle reçoit une mauvaise liste en
> paramètre.
> 
> C'est comme ça que j'analyse la chose, mais il n'est pas certain que mon
> raisonnement soit le bon.

À priori, cela a l'air d'être raisonnable comme explication.

> tu peux essayer de trouver un package qui ait le même style de .prerm
> pour comparer et voir ce qu'il pourrait manquer.

Je vais tenter.

Merci pour ton aide précieuse.

Guillaume Yziquel.



Reply to: