Dpkg prompting - partitioning the problem
There have been many good suggestions about how to handle the dpkg prompting
problem, but some will require a lot of work to be useful. (I personally
would like to be able to administer a large network of machines using an
LDAP directory, and have systems pick up as much of their configuration as
possible from there.)
One thing which has not been mentioned in all this is that the great majority
of packages do not require any prompting.
I propose that we could start to tackle the problem with a new package
maintainer script called, say 'getinfo'
The getinfo script for each package would be called before its preinst and
will just return true if it has got all the information it needs. If all
the packages which are due to be installed have returned true then dpkg knows
that no prompting will be done and can proceed with the install.
(obviously a package which has no getinfo script should be regarded the same
way as one which returns false)
The getinfo scripts then pass their information in some private manner
(probably a file in /var/run/dpkg/<packagename>) to the scripts which actually
do the work.
For a first pass many packages can be unchanged apart from a getinfo which
returns true (could be a symlink to a standard script). Packages which
do need to prompt could move their current questions to getinfo and ask them
there. Some packages may really need to have a dialog with the user when they
configure (e.g. xbase could do
getinfo: 'During this upgrade xdm will be restarted - do you want to:
1) Go ahead and restart when required
2) Not restart xdm (will leave the upgrade incomplete)
3) ask again just before an XDM restart is required.
For 1 and 2 this would save the results and return true from getinfo, and
the install would behave as it does presently except that the question would
be at the start.
For 3 the getinfo script would return false, dpkg would know that there was
at least one package which would require intervention during the install and
xbase would ask again during its preinst.
We could then define helper programs for making getinfo more sophisticated,
such as an ability to get the information via various X or network or database
interfaces as required.
John Lines
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: