Debian Bug report logs - #308234
upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ferenc Engard <ferenc@engard.hu>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Mon, 09 May 2005 00:21:32 +0200

Package: slapd
Version: 2.2.23-5
Severity: grave
Justification: renders package unusable


While I have upgraded my system, slapd upgrade asked some questions, 
including directory to dump databases. The text said the default is
/var/backups/slapd-VERSION. Reading that, I simply pushed enter. After
that, the preinst script have failed, rendering slapd unconfigured.
Meanwhile, apt has upgraded my libldap2 package.

After that I have recognized that the error is that there is no default
for this setting despite of the description, I tried to set this with
dpkg-reconfigure, but it didn't asked this question again (maybe there
is a switch for that, just I didn't found it). I had to manually edit
/var/cache/debconf/config.dat (and that was not easy to find that this
file is what I have to edit :( ).

The game was not over: because of my libldap2 was upgraded, but slapd
was not installed yet, slapcat didn't run. For some unknown reason the

apt-get install slapd=2.1.23-1 libldap2=2.1.23-1

command said 'E: Version '2.1.23-1' for 'slapd' was not found', although
my old packages were still in the cache directory.

In the end, I successfully downgraded with dpkg. I still sucked with
that the dumpdir already existed, and preinst didn't like it, but it was
a piece of cake after these all.

The most screamy was when it seemed that I cannot downgrade, and I
system was useless. Do somebody have a tip what could cause that?

Regards:

Ferenc Engard


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.25
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages slapd depends on:
ii  coreutils [fileutils]       5.2.1-2      The GNU core utilities
ii  debconf                     1.4.48       Debian configuration management sy
ii  fileutils                   5.2.1-2      The GNU file management utilities 
ii  libc6                       2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libdb4.2                    4.2.52-18    Berkeley v4.2 Database Libraries [
ii  libiodbc2                   3.52.2-3     iODBC Driver Manager
ii  libldap-2.2-7               2.2.23-5     OpenLDAP libraries
ii  libltdl3                    1.5.6-6      A system independent dlopen wrappe
ii  libperl5.8                  5.8.4-8      Shared Perl library
ii  libsasl2                    2.1.19-1.5   Authentication abstraction library
ii  libslp1                     1.0.11a-2    OpenSLP libraries
ii  libssl0.9.7                 0.9.7e-3     SSL shared libraries
ii  libwrap0                    7.6.dbs-8    Wietse Venema's TCP wrappers libra
ii  perl [libmime-base64-perl]  5.8.4-8      Larry Wall's Practical Extraction 
ii  psmisc                      21.6-1       Utilities that use the proc filesy

-- debconf information excluded

Message #10 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Ferenc Engard <ferenc@engard.hu>, 308234@bugs.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Mon, 9 May 2005 08:20:23 +0200

[Message part 1 (text/plain, inline)]

Hi Ferenc, 

On Mon, May 09, 2005 at 12:21:32AM +0200, Ferenc Engard wrote:
 
> While I have upgraded my system, slapd upgrade asked some questions, 
> including directory to dump databases. The text said the default is
> /var/backups/slapd-VERSION. Reading that, I simply pushed enter. After
> that, the preinst script have failed, rendering slapd unconfigured.
> Meanwhile, apt has upgraded my libldap2 package.

Which debconf frontend to you use? I hit the same problem with the
readline frontend which does not seem to use the default value if you
just push enter but instead the empty value. Maybe the configuration
script should just replace the empty value by the default value again.

> After that I have recognized that the error is that there is no default
> for this setting despite of the description, I tried to set this with
> dpkg-reconfigure, but it didn't asked this question again (maybe there
> is a switch for that, just I didn't found it). I had to manually edit

That could be considered a bug, yes. The question is only asked before
upgrading, running dpkg-reconfigure will not ask for it but create a new
OpenLDAP directory.

> /var/cache/debconf/config.dat (and that was not easy to find that this
> file is what I have to edit :( ).

Hint: You could also use debconf-communicate for stuff like that.

> The game was not over: because of my libldap2 was upgraded, but slapd
> was not installed yet, slapcat didn't run. For some unknown reason the
> 
> apt-get install slapd=2.1.23-1 libldap2=2.1.23-1
> 
> command said 'E: Version '2.1.23-1' for 'slapd' was not found', although
> my old packages were still in the cache directory.

apt does not use packages in the cache directory unless they are still
in the packages list for that package source. IOW: Because 2.1.23-1 is
no longer in the Debian archive apt-get just forgets that they are still
available somewhere in your cache. But you can use dpkg to install them.

> In the end, I successfully downgraded with dpkg. I still sucked with
> that the dumpdir already existed, and preinst didn't like it, but it was
> a piece of cake after these all.

Erm, you mean, that you upgraded to 2.2.23 again afterwards? 

> The most screamy was when it seemed that I cannot downgrade, and I
> system was useless. Do somebody have a tip what could cause that?
 
My understanding of dpkg and apt-get says that at the time the preinst
is run the old packages should still be installed. To get the broken
state you describe, the system must have continued the installation
despite the error in the slapd preinst. Which is in fact not expected to
ever happen. 

I'll safeguard against an empty value for the dump dir...

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Ferenc Engard <ferenc@engard.hu>

To: Torsten Landschoff <torsten@debian.org>

Cc: 308234@bugs.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Mon, 9 May 2005 12:51:49 +0200 (CEST)

Hi Torsten,

On Mon, 9 May 2005, Torsten Landschoff wrote:

>> including directory to dump databases. The text said the default is
>> /var/backups/slapd-VERSION. Reading that, I simply pushed enter. After
>> that, the preinst script have failed, rendering slapd unconfigured.
>> Meanwhile, apt has upgraded my libldap2 package.
>
>Which debconf frontend to you use? I hit the same problem with the
>readline frontend which does not seem to use the default value if you

I use the readline frontend, too.

>Hint: You could also use debconf-communicate for stuff like that.

I will look at it, I didn't hear about this cmd so far... :)

>apt does not use packages in the cache directory unless they are still
>in the packages list for that package source. IOW: Because 2.1.23-1 is
>no longer in the Debian archive apt-get just forgets that they are still
>available somewhere in your cache. But you can use dpkg to install them.

Understood. Anyway, I hope nobody will make up some day with the idea
that some process should delete the cache dir regularly, as with
debian it is nearly impossible to get a (even not-so-far) old binary
package if you don't have it in your cache.

>
>> In the end, I successfully downgraded with dpkg. I still sucked with
>> that the dumpdir already existed, and preinst didn't like it, but it was
>> a piece of cake after these all.
>
>Erm, you mean, that you upgraded to 2.2.23 again afterwards?

Oh, yes, sorry, that logical step was dropped you of the list.

>
>> The most screamy was when it seemed that I cannot downgrade, and I
>> system was useless. Do somebody have a tip what could cause that?
>
>My understanding of dpkg and apt-get says that at the time the preinst
>is run the old packages should still be installed. To get the broken
>state you describe, the system must have continued the installation
>despite the error in the slapd preinst. Which is in fact not expected to
>ever happen.

I just use debian, and don't understand package handling deeply, but I
experienced that after a (preinst) install script fails, many packages
still get installed and configured. I do not know the algorithm of
which packages are allowed to be installed, but it seems that libldap2
was installed, and it made my old ldap package useless...

>I'll safeguard against an empty value for the dump dir...

It is a good idea.

Thanks for the fast reply, I hope I could help:
Ferenc

Message #22 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Torsten Landschoff <torsten@debian.org>, 308234@bugs.debian.org

Cc: Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Mon, 9 May 2005 04:19:38 -0700

[Message part 1 (text/plain, inline)]

reassign 308234 debconf
thanks

Hi guys,

On Mon, May 09, 2005 at 08:20:23AM +0200, Torsten Landschoff wrote:

> On Mon, May 09, 2005 at 12:21:32AM +0200, Ferenc Engard wrote:

> > While I have upgraded my system, slapd upgrade asked some questions, 
> > including directory to dump databases. The text said the default is
> > /var/backups/slapd-VERSION. Reading that, I simply pushed enter. After
> > that, the preinst script have failed, rendering slapd unconfigured.
> > Meanwhile, apt has upgraded my libldap2 package.

> Which debconf frontend to you use? I hit the same problem with the
> readline frontend which does not seem to use the default value if you
> just push enter but instead the empty value. Maybe the configuration
> script should just replace the empty value by the default value again.

I really think this is a bug that needs to be dealt with from the debconf
side of things.  Torsten, if you want to add a workaround to slapd, that
should be ok, but the real bug appears to be that the readline frontend is
somehow defaulting to an empty string for text values (although, not in my
testing here...).  It may be that slapd is one of the more severely affected
packages, but I'm sure it's not the only place this causes problems.

Thanks,
-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Steve Langasek <vorlon@debian.org>

Cc: Torsten Landschoff <torsten@debian.org>, 308234@bugs.debian.org, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Mon, 9 May 2005 21:11:50 -0400

[Message part 1 (text/plain, inline)]

Steve Langasek wrote:
> reassign 308234 debconf
> thanks
> 
> Hi guys,
> 
> On Mon, May 09, 2005 at 08:20:23AM +0200, Torsten Landschoff wrote:
> 
> > On Mon, May 09, 2005 at 12:21:32AM +0200, Ferenc Engard wrote:
> 
> > > While I have upgraded my system, slapd upgrade asked some questions, 
> > > including directory to dump databases. The text said the default is
> > > /var/backups/slapd-VERSION. Reading that, I simply pushed enter. After
> > > that, the preinst script have failed, rendering slapd unconfigured.
> > > Meanwhile, apt has upgraded my libldap2 package.
> 
> > Which debconf frontend to you use? I hit the same problem with the
> > readline frontend which does not seem to use the default value if you
> > just push enter but instead the empty value. Maybe the configuration
> > script should just replace the empty value by the default value again.
> 
> I really think this is a bug that needs to be dealt with from the debconf
> side of things.  Torsten, if you want to add a workaround to slapd, that
> should be ok, but the real bug appears to be that the readline frontend is
> somehow defaulting to an empty string for text values (although, not in my
> testing here...).  It may be that slapd is one of the more severely affected
> packages, but I'm sure it's not the only place this causes problems.

The bug is in slapd for including this text in its debconf template:

  "The default is /var/backups/slapd-VERSION"

This comes under the heading of not referring to debconf UI in a
template. Just as you don't know how debconf will choose to present a
yes/no question and thus "say yes" constructions should be avoided, you
don't know how or if a given debconf frontend handles default values[1].
Indeed a static template such as this one doesn't even know for sure
what the default value _is_; it could have been overriden.

The technical details of why debconf is not able to present a default
value with the readline frontend, when the recommended
literm-readline-gnu-perl is not installed, or with the teletype
frontend, are already explained in bug #183970. I know of no better
solution than what debconf already does, aside from perhaps refusing to
run the readline frontend without literm-readline-gnu-perl (but this
wouldn't fix the teletype frontend anyway).

I'll reassign this back to slapd if it's agreeable.

-- 
see shy jo

[1] For example, the white mice debconf frontend[2] cannot offer a default
    value to the mice as they decide which tunnel to run down in the
    debconf maze. They have to choose right or left, and any debconf
    template telling them there is a default is obviously wrong.
[2] Cheezy, I know, but I'm running out of useful hypothetical debconf
    frontends. Besides, doom is passe and HHGTTG is back in.

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: Joey Hess <joeyh@debian.org>, 308234@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>, Torsten Landschoff <torsten@debian.org>, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Tue, 10 May 2005 07:17:29 +0200

> The bug is in slapd for including this text in its debconf template:
> 
>   "The default is /var/backups/slapd-VERSION"
> 
> This comes under the heading of not referring to debconf UI in a
> template. Just as you don't know how debconf will choose to present a
> yes/no question and thus "say yes" constructions should be avoided, you
> don't know how or if a given debconf frontend handles default values[1].
> Indeed a static template such as this one doesn't even know for sure
> what the default value _is_; it could have been overriden.


Interesting to know.

I indeed just nagged the openldap package maintainers (especially
Torsten who kindly followed all my suggestions) to have the debconf
templates more DTSG-compliant (and, for instance, remove a few "say
yes" instances).

However, I didn't knew about that specific argument to avoid
mentioning default values in static templates. This is a very
interesting argument to have when requesting for templates changes.

I have already felt that templates mentioning the default values is
absolutely useless anyway, as everyone is capable of figuring WHAT
default values are by just looking at what is currently in the
field..:-). So, most of the time, templates saying "The default value
is....." is just useless verbosity (and annoyance to translators).

I should write some additionnal recommendations about this in the
chapter about debconf templates in the DR manual. I suppose you agree
with me stealing your own words for that, Joey?

Message #39 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: Steve Langasek <vorlon@debian.org>, 308234@bugs.debian.org, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Tue, 10 May 2005 09:34:25 +0200

[Message part 1 (text/plain, inline)]

Hi Joey, 

On Mon, May 09, 2005 at 09:11:50PM -0400, Joey Hess wrote:
> > I really think this is a bug that needs to be dealt with from the debconf
> > side of things.  Torsten, if you want to add a workaround to slapd, that
> > should be ok, but the real bug appears to be that the readline frontend is
> > somehow defaulting to an empty string for text values (although, not in my
> > testing here...).  It may be that slapd is one of the more severely affected
> > packages, but I'm sure it's not the only place this causes problems.
> 
> The bug is in slapd for including this text in its debconf template:
> 
>   "The default is /var/backups/slapd-VERSION"

How is that a bug? In fact this can be helpful in case you changed the
value and later wonder what is was originally. Apart from that it is an
example how to use the VERSION tag.

> This comes under the heading of not referring to debconf UI in a
> template. Just as you don't know how debconf will choose to present a
> yes/no question and thus "say yes" constructions should be avoided, you
> don't know how or if a given debconf frontend handles default values[1].

So you suggest removing that string and leaving the user completely in
the dark what to enter which is utterly needed especially if the debconf
frontend ignores the default value. 

> Indeed a static template such as this one doesn't even know for sure
> what the default value _is_; it could have been overriden.

By whom? As I am the maintainer of slapd I expect nobody else to change
that default. 

> The technical details of why debconf is not able to present a default
> value with the readline frontend, when the recommended
> literm-readline-gnu-perl is not installed, or with the teletype
> frontend, are already explained in bug #183970. I know of no better
> solution than what debconf already does, aside from perhaps refusing to
> run the readline frontend without literm-readline-gnu-perl (but this
> wouldn't fix the teletype frontend anyway).

This is a silly discussion. We are saying that debconf ignores the
default value when using a special frontend which is bad. This makes it
especially senseful to add the default value to the template as
otherwise the user is completely in the dark (experienced staff aside). 

On this grounds you argue that we should /remove/ that default value
because debconf can't handle it?


If you really think we should not mention the default value there that's
okay but on the other side I request that the behaviour of the readline
frontend is changed to at least present the user the current/default
value if the libterm-readline-gnu-perl package is not installed. And
make it very clear that hitting return means submitting an empty value. 

Perhaps it's even better (for compatibility with the readline-installed
case) to ask the user to explicitly input "" for the empty value.

> I'll reassign this back to slapd if it's agreeable.

In case you do - what is the right action of slapd here? I'd rather
avoid running each db_go in a loop which checks the input values.

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Joey Hess <joeyh@debian.org>, 308234@bugs.debian.org

Cc: Torsten Landschoff <torsten@debian.org>, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Tue, 10 May 2005 05:01:15 -0700

[Message part 1 (text/plain, inline)]

On Mon, May 09, 2005 at 09:11:50PM -0400, Joey Hess wrote:
> > I really think this is a bug that needs to be dealt with from the debconf
> > side of things.  Torsten, if you want to add a workaround to slapd, that
> > should be ok, but the real bug appears to be that the readline frontend is
> > somehow defaulting to an empty string for text values (although, not in my
> > testing here...).  It may be that slapd is one of the more severely affected
> > packages, but I'm sure it's not the only place this causes problems.

> The bug is in slapd for including this text in its debconf template:

>   "The default is /var/backups/slapd-VERSION"

> This comes under the heading of not referring to debconf UI in a
> template. Just as you don't know how debconf will choose to present a
> yes/no question and thus "say yes" constructions should be avoided, you
> don't know how or if a given debconf frontend handles default values[1].
> Indeed a static template such as this one doesn't even know for sure
> what the default value _is_; it could have been overriden.

> The technical details of why debconf is not able to present a default
> value with the readline frontend, when the recommended
> literm-readline-gnu-perl is not installed, or with the teletype
> frontend, are already explained in bug #183970. I know of no better
> solution than what debconf already does, aside from perhaps refusing to
> run the readline frontend without literm-readline-gnu-perl (but this
> wouldn't fix the teletype frontend anyway).

> I'll reassign this back to slapd if it's agreeable.

Aha, ok.  Well, it's agreeable enough to me, given that this seems to
already be a known bug that isn't readily fixable.  It appears Torsten has
other comments. :)  AIUI, this was being worked around in the slapd scripts
anyway...

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #49 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Torsten Landschoff <torsten@debian.org>

Cc: Steve Langasek <vorlon@debian.org>, 308234@bugs.debian.org, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Tue, 10 May 2005 13:14:25 -0400

[Message part 1 (text/plain, inline)]

Torsten Landschoff wrote:
> > The bug is in slapd for including this text in its debconf template:
> > 
> >   "The default is /var/backups/slapd-VERSION"
> 
> How is that a bug? In fact this can be helpful in case you changed the
> value and later wonder what is was originally. Apart from that it is an
> example how to use the VERSION tag.
> 
> > This comes under the heading of not referring to debconf UI in a
> > template. Just as you don't know how debconf will choose to present a
> > yes/no question and thus "say yes" constructions should be avoided, you
> > don't know how or if a given debconf frontend handles default values[1].
> 
> So you suggest removing that string and leaving the user completely in
> the dark what to enter which is utterly needed especially if the debconf
> frontend ignores the default value. 

There's nothing stopping you from including an example value in the
template. Don't present it as the default value.

> > Indeed a static template such as this one doesn't even know for sure
> > what the default value _is_; it could have been overriden.
> 
> By whom? As I am the maintainer of slapd I expect nobody else to change
> that default. 

Preseeding? Derived distributions?

> If you really think we should not mention the default value there that's
> okay but on the other side I request that the behaviour of the readline
> frontend is changed to at least present the user the current/default
> value if the libterm-readline-gnu-perl package is not installed. And
> make it very clear that hitting return means submitting an empty value. 

It does. It prompts as follows:

  Directory to dump databases: _

Barring some note that tells them there is a default, noone would expect
hitting enter to result in some default value here[1]. The convention is
that this means there is a default value:

  Directory to dump databases [/var/backups/slapd-VERSION]: _

Or this:

  Directory to dump databases: /var/backups/slapd-VERSION_

Debconf uses one or the other of these conventions when possible. Only
experienced users use these frontends, and experienced users are
expected to be aware of these conventions.

> Perhaps it's even better (for compatibility with the readline-installed
> case) to ask the user to explicitly input "" for the empty value.

And then users need to learn a complicated set of rules for the edge
cae where they want to enter a literal pair of double quotes. No thanks.

> > I'll reassign this back to slapd if it's agreeable.
> 
> In case you do - what is the right action of slapd here? I'd rather
> avoid running each db_go in a loop which checks the input values.

Why? Validating user input is the correct thing to do in all cases
anyway.

-- 
see shy jo

[1] The only general exception to this rule I know of in all of unix/Debian
    is bootloaders.

[signature.asc (application/pgp-signature, inline)]

Message #54 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Ferenc Engard <ferenc@engard.hu>

To: Joey Hess <joeyh@debian.org>

Cc: Steve Langasek <vorlon@debian.org>, Torsten Landschoff <torsten@debian.org>, 308234@bugs.debian.org, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Wed, 11 May 2005 10:55:34 +0200 (CEST)

Hi all,

>The technical details of why debconf is not able to present a default
>value with the readline frontend, when the recommended
>literm-readline-gnu-perl is not installed, or with the teletype
>frontend, are already explained in bug #183970. I know of no better

Just a silly question: why debconf permits to select the readline
frontend if this package is not installed? It is quite embarrassing.
Anyway, I have never heard about this package so far...

Ferenc

Message #59 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Ferenc Engard <ferenc@engard.hu>

To: Joey Hess <joeyh@debian.org>

Cc: Torsten Landschoff <torsten@debian.org>, Steve Langasek <vorlon@debian.org>, 308234@bugs.debian.org, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Wed, 11 May 2005 11:26:44 +0200 (CEST)

Hi,

>> If you really think we should not mention the default value there that's
>> okay but on the other side I request that the behaviour of the readline
>> frontend is changed to at least present the user the current/default
>> value if the libterm-readline-gnu-perl package is not installed. And
>> make it very clear that hitting return means submitting an empty value.
>
>It does. It prompts as follows:
>
>  Directory to dump databases: _
>
>Barring some note that tells them there is a default, noone would expect
>hitting enter to result in some default value here[1]. The convention is
>that this means there is a default value:
>
>  Directory to dump databases [/var/backups/slapd-VERSION]: _
>
>Or this:
>
>  Directory to dump databases: /var/backups/slapd-VERSION_

I suggest that the frontend should explicitly indicate if it cannot
handle default values, although the there is one, e.g. like this:

Default value: /var/backups/slapd-VERSION
*** WARNING! You have to type the default value verbatim to use it!
Directory to dump databases: _

I feel important to first display the default value, and then the
warning message. (Please rephrase it if needed, as I am not a native
English.)

Another solution could be if the frontend asks a yes/no question to
use the default value, if the question has one.

>Debconf uses one or the other of these conventions when possible. Only
>experienced users use these frontends, and experienced users are
>expected to be aware of these conventions.

I use readline frontend because I use debian since 5-6 years, and that
time this was the only one with which I could look what happened so
far (I do not know whether there are others now). And I was not aware
that my frontend do not support default values.

Ferenc

Message #66 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Joey Hess <joeyh@debian.org>

Cc: Steve Langasek <vorlon@debian.org>, 308234@bugs.debian.org, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Fri, 13 May 2005 08:55:47 +0200

[Message part 1 (text/plain, inline)]

Hi Joey, 

On Tue, May 10, 2005 at 01:14:25PM -0400, Joey Hess wrote:
> There's nothing stopping you from including an example value in the
> template. Don't present it as the default value.

I don't like this but I won't argue it. It does not matter that much,
it's easy to remove the remark.

> > By whom? As I am the maintainer of slapd I expect nobody else to change
> > that default. 
> 
> Preseeding? Derived distributions?

Preseeding: Okay, we are talking about different "default" values here.
I am talking about the value suggested by the maintainer you are talking
about the previous value. From debconf-devel(7):

   RESET question
          This resets the question to its default value (as  is  specified
          in the 'Default' field of its template).

So I'd expect the "default value" to mean the value from the Default field. 

Derived distributions: The Default: entry of that question is just 7
lines apart from the explanation which mentions it. I'd say it's not
that hard to change both when you create a derived package.

> > frontend is changed to at least present the user the current/default
> > value if the libterm-readline-gnu-perl package is not installed. And
> > make it very clear that hitting return means submitting an empty value. 
> 
> It does. It prompts as follows:
> 
>   Directory to dump databases: _

a) It does neither present the default nor the current value.
b) It is /not/ clear that hitting enter means the empty value. With
alone this information (the above one line) that's what I would have
expected. But I was used to debconf using the default value when hitting
enter even with the readline interface. 

> Barring some note that tells them there is a default, noone would expect
> hitting enter to result in some default value here[1]. The convention is

I can proof the opposite by counterexample: I would expect it. Not on
the grounds of that output but by using debconf with readline frontend
before and just hitting enter when I did not care about a particular
setting.

> Or this:
> 
>   Directory to dump databases: /var/backups/slapd-VERSION_

Yep, I was used that from older versions of the debconf readline
interface. As a matter of fact I seldom read the full description of and
option and decide by reading 3-4 lines that the default will be okay and
hit enter.

> > Perhaps it's even better (for compatibility with the readline-installed
> > case) to ask the user to explicitly input "" for the empty value.
> 
> And then users need to learn a complicated set of rules for the edge
> cae where they want to enter a literal pair of double quotes. No thanks.

It was just a suggestion.

> Why? Validating user input is the correct thing to do in all cases
> anyway.

How do you validate if some input can be used as a directory name?
Almost any input is acceptable there (except the empty string against
which I am checking against now). 

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #71 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: Ferenc Engard <ferenc@engard.hu>

Cc: Steve Langasek <vorlon@debian.org>, 308234@bugs.debian.org, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Fri, 13 May 2005 08:57:36 +0200

[Message part 1 (text/plain, inline)]

Hi Ferenc, 

On Wed, May 11, 2005 at 11:26:44AM +0200, Ferenc Engard wrote:
> I suggest that the frontend should explicitly indicate if it cannot
> handle default values, although the there is one, e.g. like this:
> 
> Default value: /var/backups/slapd-VERSION
> *** WARNING! You have to type the default value verbatim to use it!
> Directory to dump databases: _

Yep, I thought about something along these lines.

Greetings

	Torsten

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 308234@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: Torsten Landschoff <torsten@debian.org>

Cc: Steve Langasek <vorlon@debian.org>, 308234@bugs.debian.org, Ferenc Engard <ferenc@engard.hu>, debconf@packages.debian.org

Subject: Re: Bug#308234: upgrading from 2.1.23 failed because of not setting slapd/dump_database_destdir

Date: Fri, 13 May 2005 10:28:14 -0400

[Message part 1 (text/plain, inline)]

Torsten Landschoff wrote:
> a) It does neither present the default nor the current value.
> b) It is /not/ clear that hitting enter means the empty value. With
> alone this information (the above one line) that's what I would have
> expected. But I was used to debconf using the default value when hitting
> enter even with the readline interface. 
> 
> > Barring some note that tells them there is a default, noone would expect
> > hitting enter to result in some default value here[1]. The convention is
> 
> I can proof the opposite by counterexample: I would expect it. Not on
> the grounds of that output but by using debconf with readline frontend
> before and just hitting enter when I did not care about a particular
> setting.
>
> > Or this:
> > 
> >   Directory to dump databases: /var/backups/slapd-VERSION_
> 
> Yep, I was used that from older versions of the debconf readline
> interface. As a matter of fact I seldom read the full description of and
> option and decide by reading 3-4 lines that the default will be okay and
> hit enter.

There's nothing older about it; that's the behavior of the readline
interface in the gnu readline perl binding is installed

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #81 received at 308234-close@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: 308234-close@bugs.debian.org

Subject: Bug#308234: fixed in openldap2.2 2.2.23-6

Date: Sun, 29 May 2005 13:34:57 -0400

Source: openldap2.2
Source-Version: 2.2.23-6

We believe that the bug you reported is fixed in the latest version of
openldap2.2, which is due to be installed in the Debian FTP archive:

ldap-utils_2.2.23-6_i386.deb
  to pool/main/o/openldap2.2/ldap-utils_2.2.23-6_i386.deb
libldap-2.2-7_2.2.23-6_i386.deb
  to pool/main/o/openldap2.2/libldap-2.2-7_2.2.23-6_i386.deb
openldap2.2_2.2.23-6.diff.gz
  to pool/main/o/openldap2.2/openldap2.2_2.2.23-6.diff.gz
openldap2.2_2.2.23-6.dsc
  to pool/main/o/openldap2.2/openldap2.2_2.2.23-6.dsc
slapd_2.2.23-6_i386.deb
  to pool/main/o/openldap2.2/slapd_2.2.23-6_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 308234@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Torsten Landschoff <torsten@debian.org> (supplier of updated openldap2.2 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 29 May 2005 18:23:20 +0200
Source: openldap2.2
Binary: slapd ldap-utils libldap-2.2-7
Architecture: source i386
Version: 2.2.23-6
Distribution: unstable
Urgency: low
Maintainer: Torsten Landschoff <torsten@debian.org>
Changed-By: Torsten Landschoff <torsten@debian.org>
Description: 
 ldap-utils - OpenLDAP utilities
 libldap-2.2-7 - OpenLDAP libraries
 slapd      - OpenLDAP server (slapd)
Closes: 255276 303505 306229 308234 310422
Changes: 
 openldap2.2 (2.2.23-6) unstable; urgency=low
 .
   Torsten Landschoff <torsten@debian.org>:
   * debian/po/ja.po: Merge updates from Kenshi Muto (closes: #303505).
   * debian/po/fr.po: Merge updates from Christian Perrier (closes: #306229).
   * debian/slapd.scripts-common: If the user enters the empty value for
     the database dumping directory use the default value. Seems like the
     readline interface does not care about the default value
     (closes: #308234).
   * debian/slapd.postinst: Make sure the debhelper commands are executed
     in all cases (closes: #310422).
   * Merged suggested changes by Eugene Konev to automatically run
     db_recover before starting slapd (closes: #255276).
     + debian/slapd.init: Run db_recover if enabled and available and no
       slapd process running.
     + debian/slapd.default: Add configuration option to disable it.
   * Applied and improved patch by Matthijs Mohlmann to support migration
     from ldbm to bdb backend.
     + debian/slapd.config: Ask if migration is wanted.
     + debian/slapd.postinst: Update configuration from ldbm to bdb if yes.
     + debian/slapd.scripts-common: Implemented some parts in their own
       functions.
   * Add a README.DB_CONFIG.gz and reference it where referring to BDB
     configuration.
   * Update default DB_CONFIG with some senseful values.
 .
   Steve Langasek <vorlon@debian.org>:
   * libraries/libldap_r/Makefile.in: make sure the ximian-connector ntlm
     patch is applied to libldap_r, not just to libldap
   * debian/move_files: make libldap a symlink to libldap_r, as carrying
     two versions of this library around is more trouble than it's worth,
     and can cause glorious segfaults down the line
Files: 
 1b46caee7a3377aff6ab29c3034dde86 1035 net optional openldap2.2_2.2.23-6.dsc
 20983ed8e341b87a04116cd7db075e20 489688 net optional openldap2.2_2.2.23-6.diff.gz
 80f24b17e4700ef5b8763c13f8051d3e 809150 net optional slapd_2.2.23-6_i386.deb
 8e72f04c89b139f48da941138113fa5a 118614 net optional ldap-utils_2.2.23-6_i386.deb
 73b838fd8862e1b6c2fd7e029dc84d47 151250 libs important libldap-2.2-7_2.2.23-6_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCmfsCdQgHtVUb5EcRAj1rAJwPK6SUSnp1F8D0jy5j4rUUc4CksACfdNCI
gb84g+HfrrjhwJuSVlH0CQg=
=r31z
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.