RE: dpkg modification: non-interactivity
You're both down to 33% now ;-)
The first thing to realize is that this "problem" has been solved already (numerous times). Having the interactive part of a package installation separate from the others makes sense, and is how SVR4 packages do it. This needs to be done before installing the files most of the time because the questions may have some bearing on how (and which) files get installed. Another Good Thing to do is to ship your package with sensable default answers to your questions so the users can opt not to answer any of them.
None of this requires changes to dpkg, however. The package maintainer can easily call a separate interactive script from the pre or post-inst he/she writes, or even handle interactive parts of either script in some standard fashion without requiring another script (though I like the separate interactive script idea). The main thing is being able to provide answers to the questions, either by providing an answer file, a method of querying a text database to get the answers, or answering them interactively. The answer file idea is probably my choice since it doesn't require any other boiler plate to get it going, and allows maintainers to provide a default answer file a sysadmin could use if they don't care to provide custom answers. The configuration database concept can be folded in later once the autoinstall was a reality. Perhaps a shared script should be used to procure answers to questions so that changing things later is easier?
Anyway, I'm glad to see this list getting some traffic again.
Cheers,
Rich
----------
From: Martin Bialasinski
Sent: Tuesday, December 15, 1998 6:56 AM
To: debian-admintool@lists.debian.org
Subject: Re: dpkg modification: non-interactivity
>> "MB" == Mitch Blevins <mblevin@debian.org> writes:
MB> You have the much better:
MB> / -- <wait2>
MB> DOWNLOAD <wait1> CONFIGURE --|---- <wait2>
MB> \ -- <wait2>
MB> which avoids the multiple CONFIGURE stages on the individual machines.
MB> Is there a good way to reconcile the needs of these two types of users?
MB> For the second case, would it be best just to provide more/better tools
MB> that allow the admin to change the conffiles and/or installscripts
MB> within a .deb without having to get mired down in packaging details?
This would require, that the user makes the installationscript
non-interaktive.
He has to understand it and make the necessary changes. He may even
have to do some serious coding, if he want to provide different
answers to a question, depending on the machine the package installs
to.
This also won't address dpkg asking if it may overwrite a conffile.
Maybe some kind of expect script could be used.
Problem:
The packages have to be sorted, then extracted, and then, dpkg
--configure has to be called for each package in a specific order
(with the generated expect file), so the process won't stop because
packages A complains about package B not beeing fully installed
This requires a "master" workstation to do a sample install, so that a
proper expect script can be generated.
MB> (who is proud to now have posted 100% of the traffic to this list
MB> for the month of December)
Now you are down to 50 % :-)
Ciao,
Martin
--
To UNSUBSCRIBE, email to debian-admintool-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: