Re: De l'interet de debconf (was: Pb de backport)
georges mariano [EMAIL PROTECTED] writes:
ok, mais pourquoi ne pas aller plus loin, et avoir la possibilité
__d'annuler__ l'existence de debconf pour une machine donnée ?
J'ai compris cela depuis le début mais tu n'as toujours pas expliqué
pourquoi tu veux te débarrasser de debconf sachant que ce programme
occupe peu de place sur les système et peut être désactivé.
Est-ce (bien?) l'idée du fichier suivant ??
[more /etc/apt/apt.conf.d/70debconf
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
]
Non, ceci sert à utiliser debconf avant l'installation des paquets,
quand on utilise APT.
Si on imagine une échelle des systèmes avec le critère de la capacité
de réglage, ça va du tout à la main (à l'extrème Linux From Scratch)
au tout par l'install système (type Macintosh, Windows). Avec un
outil comme debconf, Debian peut se déplacer sur cette échelle. C'est
bien. Mais Debian doit préserver la liberté de l'utilisateur et en
particulier celle de __ne pas utiliser__ un outil/une fonctionnalité.
Mais je ne vois pas en quoi avoir debconf sur ton système, même désactivé,
te dérange. Il a été conçu pour unifier les interfaces pour tous les
paquets qui posent des questions. Si beaucoup l'utilisent, tu l'aura sur
ton système à la première installation de toute manière.
Il ne suffit pas que l'utilisattion de cet outil soit invisible mais
il faut également que l'existence même de l'outil ne soit pas un
obstacle à ce que veux faire l'utilisateur. De ce point de vue, la
politique de dépendance autour de debconf me semble trop forte... et
(envisager de) rendre debconf obligatoire me semble incongru.
J'aimerai bien avoir des exemples pour juger si debconf est réellement
un obstacle.
--
Jérôme Marant [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://marant.org
Re: De l'interet de debconf (was: Pb de backport)
c'est marrant, je remonte juste d'un petit café ;-) (sans jeu de mots) On 27 Dec 2001 14:16:01 +0100 [EMAIL PROTECTED] (Jérôme Marant) wrote: J'ai compris cela depuis le début mais tu n'as toujours pas expliqué pourquoi tu veux te débarrasser de debconf sachant que ce programme occupe peu de place sur les système et peut être désactivé. ce n'est pas le programme en soit qui me gène, c'est les dépendances qui vont avec... Mais je ne vois pas en quoi avoir debconf sur ton système, même désactivé, te dérange. [en temps normal, ça ne me dérange pas ...] Pour la raison suivante : - le fonctionnement de Linux est fondamentalement basé sur la juxtaposition d'applis (ça communique ensuite par des pipes, des ports, des sockets, on s'en moque) - cette organisation est préservée dans les systèmes de packages je peux enlever un système d'impression et le remplacer par un autre, un serveur web par un autre etc etc - en particulier, __en cas de pépin__, je peux changer une roue sans démonter de manière préventive le carburateur (c'est une image...) bon, l'un de mes soucis en tant qu'admin (bénévole ;-) c'est la stabilité de mon système. Imaginons un pépin avec au hasard fileutils, (pépin d'upgrade, d'erreur de manip, on s'en moque). Evidemment je choisi fileutile parce que debconf en depend. Et bien, la moindre manip de maintenance qui remettrait en cause l'install de debconf sur cette machine, me conduit à quasiment tout désinstaller ... Debconf est une sorte de poutre qui traverse tout mon système et le rend quasi-monolitique en cas de pépin mal placé (et par application de la loi de Murphy...) J'aimerai bien avoir des exemples pour juger si debconf est réellement un obstacle . debconf n'est pas un obstacle. C'est un outil certes intéressant mais qu'il convient de replacer dans son contexte. Avant debconf, un système linux est un formidable meccano, cela doit le rester avec debconf. Debconf doit/peut être une pièce du puzzle et non pas le cadre qui recolle tout ensemble. Ce serait dommage. On doit _pouvoir_ retirer la carte debconf sans que le reste du chateau s'écroule. A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: De l'interet de debconf (was: Pb de backport)
On 21 Dec 2001 15:59:53 +0100
[EMAIL PROTECTED] (Jérôme Marant) wrote:
Tu peux demander à debconf de ne pas te poser de questions.
Dans ce cas là, les fichiers de configuration auront des
valeurs par défaut. C'est tout.
ok, mais pourquoi ne pas aller plus loin, et avoir la possibilité
__d'annuler__ l'existence de debconf pour une machine donnée ?
Est-ce (bien?) l'idée du fichier suivant ??
[more /etc/apt/apt.conf.d/70debconf
// Pre-configure all packages with debconf before they are installed.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
]
Si on imagine une échelle des systèmes avec le critère de la capacité
de réglage, ça va du tout à la main (à l'extrème Linux From Scratch)
au tout par l'install système (type Macintosh, Windows). Avec un
outil comme debconf, Debian peut se déplacer sur cette échelle. C'est
bien. Mais Debian doit préserver la liberté de l'utilisateur et en
particulier celle de __ne pas utiliser__ un outil/une fonctionnalité.
Il ne suffit pas que l'utilisattion de cet outil soit invisible mais
il faut également que l'existence même de l'outil ne soit pas un
obstacle à ce que veux faire l'utilisateur. De ce point de vue, la
politique de dépendance autour de debconf me semble trop forte... et
(envisager de) rendre debconf obligatoire me semble incongru.
Je ne trouve pas d'autres exemple d'outils (linux) ayant le status que
l'on souhaite donner à debconf ... (mais je connais pas tout!!)
Sinon, rien à dire sur l'utilisation graduelle de debconf en soit...
PS : j'ai pas encore pris mon café, aucune idée si ce que je dis
est possible...
Je t'ai largement laissé le temps de prendre ton café là. :-)
c'est fait (et plus d'une fois ;-)
--
mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06
INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59
BP 317 -- 59666 Villeneuve d'Ascq
http://www3.inrets.fr/estas/mariano
Re: Pb de backport
On Thu, 20 Dec 2001 11:30:14 +0100 [EMAIL PROTECTED] (Denis Barbier) wrote: Debconf dépend de fonctionnalités apparues avec Perl 5.6 ok. Le problème quand on backporte, c'est qu'une fois qu'on a installé perl5.6 pour une bonne raison (pour un paquet x), il est difficile de détecter ensuite une sur-dépendance sur ce paquet puisqu'il est installé ... ;-) [en toute rigueur, il faudrait perpétuellement installé/désinstallé en fonction de chaque paquet backporté !!] Est-ce que tu confirmes qu'il faut recompiler les modules Perl qu'on utilise ? Je n'ai pas compris ta réponse. et si j'ai pas compris la question ? :-) En fait la réponse dépend de la raison pour laquelle tu fais du backport. En ce qui me concerne, je souhaite recompiler tout paquet debian qui entre dans mon sous-réseau, les machines concernées s'alimentent ensuite sur une source interne. Ceci conduit donc naturellement à backporter les paquets (les machines sont potato initialement). Dans ce cas, tout est backporté... i.e sauf exception, aucune machine ne récupère directement un paquet _binaire_ woody. C'est le cas extrémiste. Une autre attitude consiste à jongler sur les sources (et options de apt) pour pointer sur le bon paquet (potato ou woody) au grés du besoin. En ce sens, il est possible de backporté la base perl mais de récupérer ensuite sur woody d'autres modules perl. Ici, je me repose sur la cohérence des dépendances Debian en place. Je ne dirai donc pas il _faut_ recompiler les modules Perl. Je dirai simplement que dit apt-get -s install le-module-que-je-veux? Ensuite je décide en fonction de ma policy locale... PS : en gros les machines Debian pointent en binaire sur des sources potato/stable (debian, ximian, xfree ...) et en deb-src pour le reste... quand un apt-get install coince, on avise ... PS2 : dans l'intervalle debconf s'est recompilé _automatiquement_ sur ma machine woody, on va pouvoir commencer à étudier son cas ... ;-) A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Pb de backport
On Thu, Dec 20, 2001 at 11:36:35AM +0100, georges mariano wrote: [...] Est-ce que tu confirmes qu'il faut recompiler les modules Perl qu'on utilise ? Je n'ai pas compris ta réponse. [...] Je ne dirai donc pas il _faut_ recompiler les modules Perl. Je dirai simplement que dit apt-get -s install le-module-que-je-veux? Ensuite je décide en fonction de ma policy locale... Et les modules Perl qui étaient auparavant installés, est-ce qu'ils continuent de fonctionner ? Je pense que non, et c'est AMHA un point qu'il faut prendre en considération avant d'installer un backport de Perl sur sa machine. Il faut certainement réinstaller les modules, ainsi peut-être que certaines applications qui en dépendent. Bref, si je devais backporter un paquet qui dépend d'une version récente de debconf, je pense que je choisirai plutôt de virer la configuration via debconf et donc la dépendance, et ferai la configuration à la main. Denis
Re: Pb de backport
Le Thu, 20 Dec 2001 13:51:57 +0100 Denis Barbier a gravé sur son écran à l'aide de son clavier: Je voulais simplement répondre à la question originale, qui concerne le blocage d'un rétroportage à cause d'une dépendance sur un debconf récent. AMHA la solution la plus simple consiste à supprimer l'utilisation de debconf dans ledit paquet. D'accord, mais il y a t'il un moyen simple de le faire ??? Sans avoir à triffouiller pendant 2h dans les sources. Parce que j'ai commencer à chercher mais je n'ai pas trouvé comment désamorcé le debconf :( Merci Seb -- MEI Sébastien [EMAIL PROTECTED] CRI - ENS Lyon http://www.ens-lyon.fr
Re: Pb de backport
On Thu, 20 Dec 2001 15:14:37 +0100 MEI Sébastien [EMAIL PROTECTED] wrote: D'accord, mais il y a t'il un moyen simple de le faire ??? Sans avoir à triffouiller pendant 2h dans les sources. Parce que j'ai commencer à chercher mais je n'ai pas trouvé comment désamorcé le debconf :( Je suis dessus et j'ai bon espoir... ;-) en fait les problèmes que je rencontre actuellement sont dus à d'autres paquets dont debconf dépend... mais là c'est plus du backport, c'est de la spéléo ... !! A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano
Re: Pb de backport
georges mariano wrote: On 20 Dec 2001 14:55:02 +0100 [EMAIL PROTECTED] (Jérôme Marant) wrote: Maintenant, si debconf est tellement buggé qu'on veuille l'enlever, il faut en discuter avec l'auteur/bugger ;-) attention Jérôme, tu (re)détourne ce que j'ai dis!! je n'ai pas dis que l'on peut vouloir enlever debconf parce qu'il était buggé ... j'ai dis, (autre formulation) puisque debconf est une partie du système dont l'utilité (réelle!) est éphémère à l'échelle de la vie d'un système stable (e.g salle de TP info avec les bonnes applis déjà installées), on peut vouloir l'enlever sans pour autant que cela empèche l'utilisation des applis. Ce n'est pas le cas. C'est tout ce que je dis... En fait, il faudrait que debconf soit touché par une dépendance particulière : install-depends :) Qu'on puisse retirer tout ce qui est install-depends, mais qu'on en aurait besoin pour tout upgrade ou install du paquet ;) PS : C'est de l'humour. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: Pb de backport
Le Thu, 20 Dec 2001 15:20:14 +0100 [EMAIL PROTECTED] écrivait : En fait, il faudrait que debconf soit touché par une dépendance particulière : install-depends :) Qu'on puisse retirer tout ce qui est install-depends, mais qu'on en aurait besoin pour tout upgrade ou install du paquet ;) PS : C'est de l'humour. Pas tant que cela : cela ajouterai juste un champ de plus à ma théorie des dépendances minimales d'un paquet. On n'est plus à un champ près :-) PK -- Patrice KARATCHENTZEFF STMicroelectronics Tel: 04-76-92-67-95 850, rue Jean Monnet 38926 CROLLES Cedex, France Courriel: [EMAIL PROTECTED]
Re: Pb de backport
georges mariano [EMAIL PROTECTED] writes: attention Jérôme, tu (re)détourne ce que j'ai dis!! Ok, alors j'ai compris que tu voulais l'enlever mais pas la raison de cette suppression. Ça ne peut pas être un problème de place disque. puisque debconf est une partie du système dont l'utilité (réelle!) est éphémère à l'échelle de la vie d'un système stable (e.g salle de TP info avec les bonnes applis déjà installées), on peut vouloir l'enlever sans pour autant que cela empèche l'utilisation des applis. Je pense que debconf deviendra « Essential » un jour ou l'autre donc il ne sera plus question de le supprimer (bientôt obligatoire dans la Debian Policy). -- Jérôme Marant
Re: Pb de backport
georges mariano [EMAIL PROTECTED] writes: Tu cherchais une raison pour laquelle je ne veux pas être développeur Debian ... en voilà une ... des fois je me demande si une idée est valide avant d'être mise dans la policy ou si c'est le fait de la mettre dedans qui la valide ... Ce qui entre dans la policy est toujours discuté publiquement avant. Comme on dit : « Qui ne dit rien consent ». Il arrive bien souvent de voir des blocages à l'issue de discussions qui conduisent à ne prendre aucune décision. Et c'est souvent mieux de ne rien décider que de le faire et risquer des voir les contributeurs partir. Ce que j'ai dit sur Debconf n'est pour l'instant qu'une recommendation dans la Policy. Debconf peut aussi évoluer de son côté si suffisamment de personnes n'en sont pas satisfaites. -- Jérôme Marant
Pb de backport
Bonjour, J'ai un petit problème de backport. J'essaye de backporter certains paquets mais si la compilation se passe bien. apt-get source --build paquet Mais le pb c'est qu'il faut un debconf supérieur à celui de la potato mais je ne souhaite pas l'upgrader. L'erreur est : Can't locate Debconf/Client/ConfModule.pm in @INC Quelqu'un sait comment parer à celà ? Merci Seb -- MEI Sébastien [EMAIL PROTECTED] CRI - ENS Lyon http://www.ens-lyon.fr
