Re: dpkg modification: non-interactivity
>>>>> "TL" == Torsten Landschoff <t.landschoff@gmx.net> writes:
TL> I do not know much about shell programming, but could we
TL> modify dpkg to stop a program that waits for input?
We could, but I think that this is over-complicating things. There
shouldn't be a dozen and one nifty ways to ask the user for
information. Let's just use a thin layer that knows enough to divert
pressing configuration questions until later.
TL> Just another thought I just got - policy says postinst should
TL> be omnipotent.
ITYM idempotent :)
TL> I like that idea. Could we scan all the postinst-scripts for
TL> interactive input to see what is needed?
I don't really think that that is necessary. As problems arise,
they'll be solved. A configuration database and a manually configured
package should have no trouble co-existing.
TL> Okay - let's implement some simple tools and see what the
TL> community thinks about it :)
Just before I do that, let me raise another point and propose a
simple initial solution. Variable descriptions. I like the idea of
people being able to get packages out the door without needing to
check back and forth with too many people. So, I think a solution
requires packages to supply their own variable descriptions. So, one
could have a /usr/lib/dpkg-config/methods tree, with, as previously
suggested, a variable hierarchy like mail/smarthost and
daemon/xntp3/peers (or whatever). Under that would be one file per
configuration variable which would contain a simple <1 line
description, a somewhat more verbose description (if someone selects
help), and possibly a link to an external site or local HTML document
if a full exposition on the subject is required. In time, this would
be backed up by a databse which also stores hooks (stuff to run if the
variable changes value, etc).
So, a new package can drop package-specific variable descriptions
neatly into that hierarchy, run update-variables, and forget about
them, other than filing a bug report against whichever package they
should be moved into. The question of which package /should/ contain
them I'll leave open.
This is all implementation details, but the implementation of this
as a first cut will take noticeably less time to write than this mail
took to compose, so please do offer feedback.
m.
Reply to: