Subject: Re: fixing debconf stdin bug

From: Adam Heath <[email-masked]>
Date: Mon, 12 Jan 2004 13:56:10 -0600 (CST)

On Sun, 11 Jan 2004, Joey Hess wrote:

> Right, I'm fairly sure that at least a few daemons have been modified
> for debian, perhaps changed to close only fd 3, and would trip over this
> sort of change.

Such debian-modified daemons are buggy.  They should not be closing just fd 3,
but be doing it correctly.

---

From: Mark Brown <[email-masked]>
Date: Sun, 11 Jan 2004 23:23:16 +0000

> for debian, perhaps changed to close only fd 3, and would trip over this

There will be a number of daemons that will only close file descriptors
0, 1 and 2 (I know at least one of my packages does this).  Using
db_stop before starting the daemon handles the Debconf control fd.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

---

From: Joey Hess <[email-masked]>
Date: Sun, 11 Jan 2004 18:08:01 -0500

Andreas Metzler wrote:
> If I understand you correctly this kind of problem depends on the
> _daemon's_ sourcecode and not only on the maintainerscript and cannot
> reliably be found just by checing the latter, but by installing the
> package, can it?

I regard this as an api change for a library, and if I accept it I will
probably do so by changing the library's "soname" -- which in this case
means adding a new version of /usr/share/debconf/confmodule under a new
name.

I have not decided if I will accept this change, since it conflicts with
how debconf is intended to be used on a philosphical level. Do I really
want to make it easier for postinst scripts to bypass debconf in
prompting the user, an action which is now deprecated by policy?

-- 
see shy jo

---

From: Manoj Srivastava <[email-masked]>
Date: Mon, 12 Jan 2004 02:13:52 -0600

On Sun, 11 Jan 2004 18:08:01 -0500, Joey Hess <[email-masked]> said: 

> I have not decided if I will accept this change, since it conflicts
> with how debconf is intended to be used on a philosphical level. Do
> I really want to make it easier for postinst scripts to bypass
> debconf in prompting the user, an action which is now deprecated by
> policy?

	Policy merely states that you must needs use a debconf like
 mechanism to talk to the user -- something that follows the policy
 spec. That does not imply that debconf has sole rights -- one could
 well have an alternate mechanism to talk to the user, which is policy
 compliant, and not debconf.

	Hence, stealing away stdin is a bug.

	manoj
-- 
The value of a program is proportional to the weight of its output.
Manoj Srivastava   <[email-masked]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

---

From: Joey Hess <[email-masked]>
Date: Tue, 13 Jan 2004 18:14:38 -0500

> 	Hence, stealing away stdin is a bug.

No, policy specifies that scripts should prompt by communicating with a
program such as debconf which implements the Debian Configuration
management specification. That specification, as I pointed out before,
requires that said communication be done using stdio. 

Debconf does not "steal" anything. If you choose to use it, you
communicate with it using stdio.

-- 
see shy jo

---

From: Manoj Srivastava <[email-masked]>
Date: Tue, 13 Jan 2004 21:09:53 -0600

On Tue, 13 Jan 2004 18:14:38 -0500, Joey Hess <[email-masked]> said: 

>> well have an alternate mechanism to talk to the user, which is
>> policy compliant, and not debconf.
>>

> No, policy specifies that scripts should prompt by communicating
> with a program such as debconf which implements the Debian
> Configuration management specification. That specification, as I
> pointed out before, requires that said communication be done using
> stdio.

> communicate with it using stdio.

	What if I chose to use two such frontends? There is nothing in
 policy that states that each script should communicate with one and
 only one debconf like program.

	In theoryu, I can ask a dozen questions, each using a
 different debconf like program -- and be policy compliant.

	How does the second, third and so forth program get hold of
 STDIN?

	manoj
-- 
"If people are good only because they fear punishment, and hope for
reward, then we are a sorry lot indeed." Albert Einstein
Manoj Srivastava   <[email-masked]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

---

From: Joey Hess <[email-masked]>
Date: Wed, 14 Jan 2004 00:38:52 -0500

> 	How does the second, third and so forth program get hold of

This is not something that I have the least little interest in trying to
support, for a wide variety of reasons that I will not go into here.

-- 
see shy jo

---

From: Manoj Srivastava <[email-masked]>
Date: Wed, 14 Jan 2004 00:45:57 -0600

On Wed, 14 Jan 2004 00:38:52 -0500, Joey Hess <[email-masked]> said: 

>> In theoryu, I can ask a dozen questions, each using a different
>> debconf like program -- and be policy compliant.
>>
>> How does the second, third and so forth program get hold of STDIN?

> This is not something that I have the least little interest in
> trying to support, for a wide variety of reasons that I will not go
> into here.

	I can understand that -- you have written debconf, and it
 probably perfectly satisfies your needs, and behaves in a fashion
 that feels absolutely natural and logical to you. but that does not
 mean that the current behaviour is one that would be optimal for
 other folks -- especially those considering writing another program
 that adheres to the debconf  spec.

	manoj
-- 
To err is human, but I can REALLY foul things up.
Manoj Srivastava   <[email-masked]>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

---

From: Joey Hess <[email-masked]>
Date: Wed, 14 Jan 2004 02:31:21 -0500

Manoj Srivastava wrote:
> that feels absolutely natural and logical to you.

That has nothing to do with my reasons for feeling this is a bad idea.
In fact I've done a fair bit of work on transitioning us to cdebconf
(which I did not write) and expect to do more. Moreover, as with most
software I write (or paintings I paint..), I can see problems in debconf
that most people are not particularly aware of.

My reasons have more to do with why we want to use a system like debconf
in the first place, and how something like what you're describing could
seriously undermine its advantages. Things like UI consitency, user
control, a simple frontend-agnostic protocol, etc.

As I said I'd prefer to not go into my reasons in depth here, so I'd
appreciate it if you didn't attribute incorrect reasons to me.

-- 
see shy jo

---

From: Chris Hofstaedtler <[email-masked]>
Date: Sun, 19 Jan 2025 23:49:19 +0100

Control: tags -1 - patch

> That has nothing to do with my reasons for feeling this is a bad idea.
[..]

Looks like the patch is not the patch people are looking for.