Package: dbconfig-common
Version: 1.8.28
Severity: important
Package upgrades fail if dbconfig-load-include returns empty output
during the migration from a package without dbconfig-common support.
This situation can occur if dbconfig-load-include is unable to parse the
specified configuration file, or the configuration file currently uses a
database type that is not supported by dbconfig-common.
An example from the PHPwiki package.
phpwiki is using a custom load script, eg
dbc_load_include="exec:$loadscript"
In some cases the script cannot parse the config file (it's using an
unsupported db type) and returns blank output, eg:
dbc_dbuser=''
dbc_dbpass=''
dbc_basepath=''
dbc_dbname=''
dbc_dbserver=''
dbc_dbport=''
dbc_dbtype=''
This is the same output that dbconfig-load-include outputs if run in
other modes and given a file that does not contain valid information.
dbconfig-common then tries to load the "answer" into the debconf
database, because no dbtype is set the templates it tries to use do not
exist.
+ read -r _db_internal_line
+ RET='value set'
+ case ${_db_internal_line%%[ ]*} in
+ return 0
+ db_set phpwiki//app-pass ''
+ _db_cmd 'SET phpwiki//app-pass' ''
+ IFS=' '
+ printf '%s\n' 'SET phpwiki//app-pass '
+ IFS='
'
+ read -r _db_internal_line
+ RET='10 phpwiki//app-pass doesn'\''t exist'
+ case ${_db_internal_line%%[ ]*} in
+ return 10
dpkg: error processing phpwiki (--install):
subprocess post-installation script returned error exit status 10
I think the solution to this bug is that dbconfig-common should check
the output to dbconfig-load-include to ensure that valid answers were
able to be extracted, and only load the answers into debconf if that is
true. If nothing could be read from the existing config, the user should
see a warning and dbconfig-common should proceed as if its a new
installation (ask the user if they want to use dbconfig-common, etc).
I'll see if I can come up with a patch to implement this behaviour.
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16.18
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Versions of packages dbconfig-common depends on:
ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy
ii ucf 2.0016 Update Configuration File: preserv
dbconfig-common recommends no packages.
-- debconf information:
dbconfig-common/dbconfig-upgrade: true
* dbconfig-common/remote-questions-default: true
dbconfig-common/db/basepath:
dbconfig-common/pgsql/revertconf: false
dbconfig-common/install-error: abort
dbconfig-common/pgsql/no-empty-passwords:
dbconfig-common/mysql/method: unix socket
dbconfig-common/pgsql/admin-user: postgres
dbconfig-common/dbconfig-install: true
dbconfig-common/pgsql/no-user-choose-other-method:
dbconfig-common/upgrade-backup: true
dbconfig-common/internal/reconfiguring: false
dbconfig-common/passwords-do-not-match:
dbconfig-common/pgsql/authmethod-admin: ident
dbconfig-common/remove-error: abort
dbconfig-common/internal/skip-preseed: false
dbconfig-common/db/dbname:
* dbconfig-common/remember-admin-pass: false
dbconfig-common/mysql/admin-user: root
dbconfig-common/dbconfig-reinstall: false
dbconfig-common/remote/host:
dbconfig-common/pgsql/manualconf:
dbconfig-common/pgsql/changeconf: false
dbconfig-common/remote/newhost:
dbconfig-common/pgsql/method: unix socket
dbconfig-common/pgsql/authmethod-user:
dbconfig-common/upgrade-error: abort
dbconfig-common/database-type:
dbconfig-common/dbconfig-remove: true
dbconfig-common/db/app-user:
dbconfig-common/remote/port:
dbconfig-common/purge: false
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
