[Dbconfig-common-devel] dbconfig-common in Pre-Depends?

[sean finney]

hi michael,

On Wed, 2006-09-13 at 15:03 +0200, Michael Ablassmeier wrote:
>  dbconfig-common based packages do ask their debconf questions in the
>  middle of the installation, not at the beginning (in the configure
>  state, so that postinst only has to get the selected values). This
>  is pretty annoying if you want to install some packages while beeing 
>  away. 

most of the questions are asked in the .config script.  there are a few
cases where the postinst script might invoke a debconf prompt (during
certain kinds of upgrades), but this is generally a good thing.  what
you're probably seeing is the .config script being run by dpkg just
before the postinst is being run, which is a dpkg-provided hack that
joeyh describes in debconf-devel(7).

>  When dbconfig-common is installed and configured the Packages seem
>  to ask their questions at the beginning of the installation, so 
>  this made us wonder if dbconfig-common should be in Pre-Depends.

i was pretty sure i set things up to avoid the need for a pre-depends,
but looking at things again this might not be the case.

>  There is also another example (installing webcalendar from scratch) 
>  with a package failing to install if dbconfig-common was not 
>  configured and installed:
> 
>  14:43  * kobold is apt-getting ..
>  14:44 <kobold> Preconfiguring packages ...
>  14:44 <kobold> /tmp/webcalendar.config.1795511: line 17: /usr/share/dbconfig-common/dpkg/config: No such file or directory
>  14:44 <kobold> webcalendar failed to preconfigure, with exit status 1
>  14:45 <kobold> and questions in the middle of the installation, too.
>  14:45 <kobold> now I'll try to install dbconfig-common and then webcalendar
>  14:46 <kobold> in this way it works
>  14:46 <kobold> so this is definitely a pre-depends
>  14:46 <kobold> it asks me for the db setup in the pre-configure phase.
> 
> as simply adding Pre-Depends is a no-go (withoug prior discussion), any
> thoughts about that?

i need some time when my brain isn't drained to confirm this, but you're
probably right that the current setup is buggy in this respect.

assuming that this is the case, you can do in the .config script what is
already recommended to be done in the postrm script (conditionally
sourcing / calling dbc_go).  when the config script is called for the
second time (by dpkg, before the postinst is called), you'll be
guaranteed to have your dependencies at least unpacked.  if dpkg ever
changes its behaviour and drops this second "hack" call for .config, it
can be worked around from within dbconfig-common as long as that
conditional sourcing check is done in .config.

but let me sleep on this and re-read it with a fresh brain before i give
you an authoritative reply :)


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/dbconfig-common-devel/attachments/20060914/2b2eb2f8/attachment.pgp