Re: installation oddities
Bob Hunter wrote:
> The bug is that /var/cache/debconf/config.dat
> is not being updated, so that debconfig fails
What is this "debconfig"?
> so horribly to trigger that funky syscall.
What is this "funky syscall"?
Sorry, I guess I must be missing some context.
> If you do not beleve me, then try editing
> that file, remove an entry, then try configuring
> the relative package. Nice bug eh?
>
> Now, what might be the reason causing debconf
> not to update config.dat? A completely missing
> entry should be a good reason for debconf to
> add the entry, I think. So, why is it failing?
I'm pretty sure that I posted an explination of this to a public mailing
list either yesterday or 10 days ago[1], but here goes again:
By the nature of the debconf specification, data about questions is not
tightly bound to data about templates. In particular, a template may
instantiate into zero or more questions, one of which may or may not
have the same "name" as the template. The specification also allows
questions to be created and destroyed on the fly.
As a pragmatic aid, debconf automatically creates questions derived from
and with the same name as each template it sees, the first time it sees
the template. It only does it the first time to avoid getting in the way
of anything that doesn't like those questions and chooses to remove them
leter.
Therefore, if a question is removed from config.dat, it will look to
debconf as if the question was legitimatly removed during normal debconf
operation, and since it has already seen the associated template, it
will not re-instantiate the removed question.
[
Of course, even if it were possible to know when to re-instantiate a
question in a situation where it had somehow fallen out of the
database, doing so would be a horrible idea, because it would likely
lead to highly inconsistent behaviour. Just consider the case of a
config script which asks a question. For the sake of argument, the
question is "Delete what directory hierarchy", and for the sake of
absurd examples, the default has been put in as "/", to save the user
having to type that in the front of whatever directory they decide to
delete. (The maintainer is not a complete moron; the config script
checks to see if the user leaves it at just "/" and refuses to accept
that as a valid answer..) The user correctly types in
"var/tmp/fribble", and configuration of the package completes. This
question and the user's answer is then lost from the database somehow.
Now the postinst runs, and it is going to use debconf to pull the
answer to the question out of the database and rm -rf it. But the
question isn't there, so debconf slyly re-instantiates it. Which
slips the default of "/" in as the current answer to the question.
The postinst, which lacks the sanity checks of the config script
happly creates a lot more free disk space on the user's system..
]
In summary, this is not a bug at all, but a deliberate design decision,
that makes debconf a lot more powerful, at the expense of not letting it
try to go in and make the kind of fool-hardy modifications to a
possibly-corrupted debconf database which you are suggesting.
--
see shy jo
[1] My outgoing mail queue is pretty special sometimes.
Reply to: