Bug#229648: cdebconf: "seen" handling broken
* Joey Hess
| Steinar H. Gunderson wrote:
| > On Mon, Jan 26, 2004 at 07:17:49AM +0100, Denis Barbier wrote:
| > >> Umm, main-menu definitely did this before;
| > > Main-menu calls 'udpkg --configure --force-configure' to force
| > > maintainers scripts to be run, but that's all. Either main-menu
| > > or udpkg must tell cdebconf to display seen questions.
| >
| > OK, it used to call dpkg-reconfigure, which set the environment variable. I
| > don't know who broke it and why, but it should be fixed. :-)
|
| Tollef made that change to main-menu (version 0.018), but did not say
| why in the changelog.
04:17 < Mithrandir> dpkg-reconfigure is being stupid when a frontend is already
running, it seems.
04:18 < Mithrandir> it shoud be a (more or less) no-op when it already has a fro
ntend.
04:18 < Mithrandir> right?
04:20 * Mithrandir prods tausq carefully
04:20 * tausq-h is thinking :>
04:21 < Mithrandir> ok :)
04:21 < tausq-h> doesn't dpkg-reconfigure start up its own frontend?
04:21 < Mithrandir> it tries to.
04:22 * tausq-h nods
04:22 < Mithrandir> what happens if you start a text frontend while your stdout
points to another cdebconf's input pipe?
04:22 * Mithrandir thinks the first debconf will be pretty confused.
04:22 < tausq-h> yes :)
04:23 * tausq-h was under the impression that debconf is not reentrant ?
04:23 < Mithrandir> the first time, we don't run dpkg-reconfigure, just udpkg --
configure.
04:23 * tausq-h vaguely remembers trying to do this with joey's implementation
before, it fails quite miserably (at least back then)
04:24 < Mithrandir> so, lifting udpkg's dpkg_doconfigure and running that if we
already have a frontend should be fine?
04:25 < tausq-h> what do you mean by "lifting udpkg's dpkg_doconfigure"?
04:25 < Mithrandir> static int dpkg_doconfigure(struct package_t *pkg)
04:26 < Mithrandir> copy that function into dpkg-reconfiguer
04:26 < Mithrandir> C-t
04:26 < tausq-h> wait, i don't think that's quite right...
04:26 < Mithrandir> and run that instead of everything dpkg-reconfigure does tod
ay, iff there is a frontend already?
04:27 < tausq-h> that code in udpkg only reruns the postinst right? i thought dp
kg-reconfigure already has code to do that
04:28 < tausq-h> s/postinst/config or postinst/
04:28 < tausq-h> the only question is whether we should be starting a new fronte
nd, or if there's some way to attach to an existing one?
04:28 < tausq-h> or am i not understanding this correctly?
04:28 < Mithrandir> we will attach to the current one if we don't do anything.
04:29 < Mithrandir> if we just start the config script/postinst it should just w
ork.
04:29 < tausq-h> then when are you running dpkg-reconfigure? :)
04:29 < tausq-h> s/when/why/
04:29 < Mithrandir> because dpkg --configure checks whether it's already configu
red.
04:30 < Mithrandir> and I think it's ugly to poke at dpkg's internals more than
necessary.
04:30 < Mithrandir> so, limiting it to cdebconf/udpkg makes less places to chang
e if we want to redo the internals.
04:30 * tausq-h tries an experiment
04:32 < tausq-h> i guess i'm missing something, debconf never allows you to run
two debconf sessions concurrently, why do we need to do this? i thought whenever
we needed to configure something, we would terminate the first debconf session,
do the configuring, and restart the first (main-menu) debconf session later?
04:32 < tausq-h> i *don't* want d-i specific logic in cdebconf, if we can help i
t
04:33 < Mithrandir> so you want main-menu to call db_stop, run it's thing, then
reinitialize?
04:33 < tausq-h> yes, the frontend is really the least of our worries, we don't
yet implement database locking, and things can go terribly wrong if we have two
debconf sessions running concurrently
04:34 < Mithrandir> no. They are talking to the same frontend.
04:34 < Mithrandir> and since they all play nice (no backgrounding of config scr
ipts etc) It Works.
04:36 < tausq-h> um, if you are using a rfc822 db, and main-menu has the db file
open when you call dpkg-reconfigure to configure foo, what happens to the db?
04:37 < Mithrandir> what happens today, or what should happen?
04:37 < tausq-h> both :)
04:37 < tausq-h> well, what should happen is dpkg-reconfigure will fail
04:38 < tausq-h> it will try to lock the question/template db and fail to do so
04:38 < Mithrandir> today, dpkg-reconfigure opens the dpkg, tries to communicate
, and fails miserably.
04:38 < Mithrandir> what I think should happen is that it sees "hey, I already h
ave a frontend running, let's use that".
04:39 < tausq-h> Yes, granted the frontend handling can be improved, i'm more co
ncerned about the backend
04:40 < Mithrandir> the config scripts doesn't talk directly to either, when I s
ay "frontend", I mean "debconf instance".
04:40 < Mithrandir> I think, at least.
04:40 < Mithrandir> sorry about that.
04:41 < tausq-h> well, i'm a bit rusty on how the interaction works between the
various components, so i might have gotten the sequence wrong, but my understand
ing is this:
04:42 < tausq-h> main-menu runs first as a debconf "script" right?
04:42 < Mithrandir> yes, as a config script.
04:43 < tausq-h> so at this point, it is running with one instance of debconf --
one frontend (say text) and one db module (say rfc822db, with config.dat open)
04:43 < tausq-h> right?
04:43 < Mithrandir> yes
04:43 < tausq-h> so now, i choose some option to configure the system, and witho
ut exiting the first instance of debconf, it tries to run udpkg to install/confi
gure some packages?
04:43 < Mithrandir> yes
04:44 < tausq-h> so, while main-menu has an open fd of the config.dat, udpkg/dpk
g-reconfigure will try to reopen and modify that open config.dat, don't you thin
k that's wrong?
04:45 < tausq-h> or rather, is not supported by debconf aiui
04:45 < Mithrandir> yes, that's not something we want.
04:45 < tausq-h> here i'm using "debconf" as the spec, not the implementations
04:45 < tausq-h> ok
04:45 < Mithrandir> however, there is nothing preventing udpkg from talking to t
he first debconf instance.
04:46 < tausq-h> yes, and you do not do that using dpkg-reconfigure
04:47 < tausq-h> how will dpkg-reconfigure know there's another instance of debc
onf running anyway? do you pass some environment to it?
04:47 < tausq-h> i guess DEBCONF_HAS_FRONTEND might be set...
04:48 < Mithrandir> DEBCONF_HAS_FRONTEND, yes
04:49 < Mithrandir> bingo
04:49 < Mithrandir> I fixed it in main-menu
04:49 < tausq-h> and if the fd that is being used to communicate between main-me
nu and the 1st debconf instance belongs to those processes, how does the new dpk
g-reconfigure talk to that first set of fds ?
04:49 < Mithrandir> udpkg --configure will happily reconfigure.
04:49 < Mithrandir> they are dup()-ed.
04:49 < Mithrandir> they are stdin and stdout.
04:49 < tausq-h> oh, right, duh, sorry
04:50 < tausq-h> happily reconfigure by talking to one instance? or to two insta
nces?
04:50 < Mithrandir> one.
04:50 < tausq-h> oh :
04:50 < tausq-h> )
04:50 < tausq-h> how did you do that?
04:50 < Mithrandir> just udpkg --configure
04:50 < tausq-h> *boggle*
04:51 < Mithrandir> udpkg is stupid enough that it doesn't check whether the pac
kage is already configured or not.
04:51 < Mithrandir> which suits us excellently. :)
04:51 < tausq-h> heh
04:52 < tausq-h> i'm surprised we're still using it actually, i thought busybox
has a dpkg implementation
04:52 < Mithrandir> it has, but nobody has actually taken the work it is to use
that one instead.
04:52 < tausq-h> heh
04:52 < tausq-h> i haven't looked at it, is it more or less the same as udpkg? i
know glenn was "porting" udpkg to busybox at one point
04:53 < Mithrandir> no idea.
04:53 < tausq-h> k
04:54 < tausq-h> hrm, it's gotten quite a bit bigger :)
04:54 < Mithrandir> anyhow.. it's 04:54 here now, and I guess I should catch som
e sleep. I'll run this through with Marvin-- tomorrow.. he'll probably scream a
little, but accept it.
04:54 < tausq-h> -rwxr-xr-x 1 randolph randolph 13032 Nov 23 19:49 udpkg
04:55 < tausq-h> Mithrandir: :) thanks much for wokring on all this :)
04:55 * tausq-h feels bad for making lots of noise and not contributing code
04:55 < tausq-h> but am busy on other fronts
04:56 < Mithrandir> that's ok. I appreciate the work joeyh and you've done to g
et this started and am grateful for being able to bring this project on. it's f
un and a hell of a lot bigger than anything I've done before.
05:10 * tausq-h nods, it's looking good, and i'm so glad we got rid of boot-flo
ppies :P
Yes, this should probably have gone into the changelog, but please
consider the time of day. :)
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Reply to: