Bug#206684: debian-policy: Proposal for going ahead with mandatory debconf use for prompting
On Wed, Jul 04, 2007 at 08:27:40PM +0200, Lucas Nussbaum wrote:
> On 08/03/07 at 08:02 +0100, Lucas Nussbaum wrote:
> > On 07/03/07 at 23:07 +0100, Christian Perrier wrote:
> > > > I would really like to see that happening at the beginning of the lenny
> > > > release cycle. Packages that prompt without using debconf make it
> > > > unnecessary difficult to test them using piuparts.
> > > >
> > > > Looking at my piuparts results (testing packages in etch), most packages
> > > > that prompt the user already do that through debconf, so it would not
> > > > result in more than 50 or 100 bugs (and that's the worst case scenario).
> > > Hmmm, that many?
> > > [..]
> > > I'm still puzzled by the number of package you announce, Lucas.
> > Well, that's really the worst case scenario. I would have to run
> > piuparts again to get better numbers, since:
> > - I'm running piuparts on etch, not sid, and packages
> > in-sid-but-not-in-etch are likely to be less well maintained, so
> > changes are higher that they do bad stuff with /dev/tty
> > - I use a workaround (make /dev/tty a copy of /dev/null) so that most
> > packages reading /dev/tty don't block during the test
> > I'll try to give a better estimation soon.
> Indeed, there are probably less packages to fix that I thought.
> Christian, would you be interested in pushing a lenny release goal about
Last I knew, policy said packages *were* allowed to depend on the
availability of /dev/tty during configuration, even if they're not supposed
to be doing direct prompting by way of it. This seems to have been changed,
but isn't mentioned in the policy upgrading-checklist?
Given that this has changed, I don't personally have any objections to this
proposal (and my tentative objection only had to do with the possible
methodology of fiddling with /dev/tty).
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.