hiya, On Monday 14 April 2008 12:28:33 pm Raphael Hertzog wrote: > When the database is hosted on the same server, it means that the database > server needs to be running and functional. But that's not the case if you > install the packages directly within debian-installer (the /target chroot > is temporarily configured in a way that no services are started by > invoke-rc.d, and that's a sane thing to do IMO). there are also probably a few corner cases on live systems, where the "service" is being upgraded/installed simultaneously and is not available during postinst. > This is a pain for CDD that want to auto-install some of those packages. > > How should we handle this problem? shooting from the hip here, but i suspect there may be a fairly graceful and general way of doing this, via triggers plus something like what you mention here: > A new init script has been added so that at the end of the boot sequence, > when all services have been started, another try is made for all the > registered scripts. On success, the symlink is removed, otherwise it's > kept for as long as the configuration doesn't succeed. This means that > initial configuration (usually) happens at the end of the first reboot. in the case of dbconfig-common, my thought is that it could somehow use triggers to schedule deferred execution of the database configuration stuff until the very end, after the databases are guaranteed to be back up. that should cover the problem on "live" systems. in d-i, some kind of hook could be placed on the trigger execution, such that instead of executing it at the end of dpkg's run, the commands are placed into a batch script in /var/lib/somewhere and executed by a hypothetical "firstboot" script. and generally speaking, i imagine that CDD's (as well as those doing preseeded custom installs) would appreciate having such a "firstboot" feature from dpkg, anyway. i'm not at all familiar enough with either triggers or d-i to know if this is feasible though. sean
Description: This is a digitally signed message part.