|
Home > Archive > Debian Developers > April 2004 > problem with dpkg-reconfigure and noninteractive frontend
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
problem with dpkg-reconfigure and noninteractive frontend
|
|
|
| Hi People.
Sorry, i'am new to debian and i hope i pose the right question to the right
list. I'm currently trying to use dpkg-reconfigure with the "noninteractive"
frontend on sarge, the tool is from package debconf 1.4.16.
Problem is, when i select the noninteractive frontend, either by saying
-fnoninteractive or by reconfiguring debconf to use noninteractive as the
default frontend, i find myself in the dialog frontend.
I've inspected the source and found a completely unconditional:
35 if (lc Debconf::Config->frontend eq 'noninteractive') {
36 Debconf::Config->frontend('dialog');
37 }
When i comment this out, noninteractive seems to work just great. I've read the
manpage and discovered that when you use dpkg-reconfigure to reconfigure
debconf itself, it should fallback from noninteractive to dialog. Is it
possible
that this block is meant for this but just fails to check if a reconfiguration
of debconf is in progress?
As i have urgent need for noninteractive reconfiguration, i made this patch:
--- dpkg-reconfigure.orig 2004-04-20 19:19:14.000000000 +0200
+++ dpkg-reconfigure 2004-04-20 19:21:41.000000000 +0200
@@ -32,8 +32,13 @@
if ($default_priority) {
Debconf::Config->priority(Debconf::Question->get('debconf/priority')->value);
}
-if (lc Debconf::Config->frontend eq 'noninteractive') {
- Debconf::Config->frontend('dialog');
+# in case of a reconfiguration of debconf itself, disable the noninteractive
frontend
+for(@ARGV){
+ if ($_ =~ m/^debconf$/){
+ if (lc Debconf::Config->frontend eq 'noninteractive') {
+ Debconf::Config->frontend('dialog');
+ }
+ }
}
my $frontend=make_frontend();
unless ($unseen_only) {
Is it really this or is noninteractive support disabled because of a reason
i've
failed to discover?
--
christian ramseyer
rc@networkz.ch
replace @ with (A) if you want to send spam ; )
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joey Hess 2004-04-20, 9:33 pm |
| rc wrote:
> I've inspected the source and found a completely unconditional:
> 35 if (lc Debconf::Config->frontend eq 'noninteractive') {
> 36 Debconf::Config->frontend('dialog');
> 37 }
The reason this is done is so users who have the default debconf
frontend set to noninteractive can use dpkg-reconfigure and have it do
something useful. See bug #57614.
I don't see the use of running dpkg-reconfigure with the noninteractive
frontend. What are you trying to do?
--
see shy jo
| |
| Andrew Pollock 2004-04-21, 2:33 am |
| On Tue, Apr 20, 2004 at 08:44:41PM -0400, Joey Hess wrote:
> rc wrote:
>
> The reason this is done is so users who have the default debconf
> frontend set to noninteractive can use dpkg-reconfigure and have it do
> something useful. See bug #57614.
>
> I don't see the use of running dpkg-reconfigure with the noninteractive
> frontend. What are you trying to do?
I understand the above scenario to handle the case where the default
frontend is non-interactive as opposed to dpkg-reconfigure being called with
-fnoninteractive. I certainly have made a lot of use of the latter when
using FAI, and used debconf-communicate to non-interactively configure
packages installed by FAI.
Not sure if this is contrary to your "Debconf is not a registry" views...
Andrew
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Scott James Remnant 2004-04-21, 4:34 am |
| On Tue, 2004-04-20 at 19:44 +0200, rc wrote:
> Sorry, i'am new to debian and i hope i pose the right question to the right
> list. I'm currently trying to use dpkg-reconfigure with the "noninteractive"
> frontend on sarge, the tool is from package debconf 1.4.16.
>
You want to reconfigure a package ... but don't?
I'm confused; why would you want to run dpkg-reconfigure without being
asked anything?
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
| |
| Chad Walstrom 2004-04-21, 11:34 am |
| On Wed, Apr 21, 2004 at 09:17:51AM +0100, Scott James Remnant wrote:
> I'm confused; why would you want to run dpkg-reconfigure without being
> asked anything?
Perhaps you want to update the local configuration based on changes to
an LDAP backend, i.e. a large distributed network of Debian boxen
powered by OpenLDAP... ARRR ARRRR ARRRRRRRRR THE POWER!!!!
--
Chad Walstrom <chewie@wookimus.net> http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
| |
| Branden Robinson 2004-04-21, 7:36 pm |
| On Tue, Apr 20, 2004 at 08:44:41PM -0400, Joey Hess wrote:
> rc wrote:
>
> The reason this is done is so users who have the default debconf
> frontend set to noninteractive can use dpkg-reconfigure and have it do
> something useful. See bug #57614.
>
> I don't see the use of running dpkg-reconfigure with the noninteractive
> frontend.
Maybe they're trying to re-run the postinst script.
--
G. Branden Robinson | You don't just decide to break
Debian GNU/Linux | Kubrick's code of silence and then
branden@debian.org | get drawn away from it to a
http://people.debian.org/~branden/ | discussion about cough medicine.
| |
| Steve Langasek 2004-04-21, 11:34 pm |
| On Wed, Apr 21, 2004 at 10:01:19AM -0500, Chad Walstrom wrote:
> On Wed, Apr 21, 2004 at 09:17:51AM +0100, Scott James Remnant wrote:
[vbcol=seagreen]
> Perhaps you want to update the local configuration based on changes to
> an LDAP backend, i.e. a large distributed network of Debian boxen
> powered by OpenLDAP... ARRR ARRRR ARRRRRRRRR THE POWER!!!!
And, as Debconf Is Not A Registry, most questions that are under debconf
control should give preference to the already configured local settings
over anything that would come from LDAP.
--
Steve Langasek
postmodern programmer
| |
| Christian Ramseyer 2004-04-22, 5:34 pm |
| (on|am|le) Wed, 21 Apr 2004 15:44:35 +1000, Andrew Pollock <debian-lists-2004@andrew.net.au> (said|sagte|disait):
> On Tue, Apr 20, 2004 at 08:44:41PM -0400, Joey Hess wrote:
>
> I understand the above scenario to handle the case where the default
> frontend is non-interactive as opposed to dpkg-reconfigure being called with
> -fnoninteractive. I certainly have made a lot of use of the latter when
> using FAI, and used debconf-communicate to non-interactively configure
> packages installed by FAI.
>
> Not sure if this is contrary to your "Debconf is not a registry" views...
>
> Andrew
This is exactly my case. After FAI installation, i would like to reconfigure some
packages, and i thought that i could just edit the debconf database and the do
a dpkg-reconfigure -f noninteractive. Am I on the right track, or is there a
better way to do something like this?
I've seen your FAI faq-o-matic where you say:
<faq>
There are a number of ways, probably the most "Debian way" of doing it would be
something like this:
echo "set passwd/md5 true" | debconf-communicate
dpkg-reconfigure -f noninteractive passwd
in a class specific script in $FAI_CONFIGDIR/scripts
"
</faq>
I would like this approach, especially because there may be a lot more packages to
reconfigure than only to passwd. But the current dpkg-reconfigure doesn't seem to
allow this any more.
--
christian ramseyer
rc@networkz.ch
replace @ with (A) if you want to send spam ; )
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Metzler 2004-04-22, 6:35 pm |
| Christian Ramseyer <rc@networkz.ch> wrote:
[...]
> This is exactly my case. After FAI installation, i would like to
> reconfigure some packages, and i thought that i could just edit the
> debconf database and the do a dpkg-reconfigure -f noninteractive.
[...]
Well. It will not work for packages that use debconf to manage a
configuration file and do this properly by parsing the configuration
file and syncing its values into the debconf-db.
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jerry Haltom 2004-04-23, 7:34 pm |
| I would like to ask why Debconf is not a registry. Debconf seems the
perfect vehicle for deploying settings to a number of Debian boxes. And
in fact, most of the time it is. There are a few cases, and a few
specific packages however that make it a bit of a trouble.
What my office does is store a central Debconf settings file, and an apt
mirror. Once a night, or during install, we add the network settings to
the local settings, and reconfigure each changed package. For the most
part this works perfectly. We can deploy policy changes to Debian
packages, and our own packages, very easily. It's a blessing.
However, and this was brought up recently regarding the locales package
(see bug #245337). It seems that Debconf Is Not A Registry. I'm not
quite sure what this means!
It would be EXTREMELY useful if packages were smart about local/Debconf
settings. Merging changes in both of them in order to determine the
actual setting. If one changes a local file, you would expect that
change to persist, but if one changes a Debconf setting, you would
expect that to persist. In fact, if one changes a Debconf setting
manually, I'd expect it to override local settings.... that's what
pushing settings is all about.
So... This has probably been discussed to death, why isn't it good?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2004-04-24, 1:34 am |
| On Fri, Apr 23, 2004 at 05:45:52PM -0500, Jerry Haltom wrote:
> I would like to ask why Debconf is not a registry.
Policy section 10.7.3.
> It would be EXTREMELY useful if packages were smart about local/Debconf
> settings. Merging changes in both of them in order to determine the
> actual setting. If one changes a local file, you would expect that
> change to persist, but if one changes a Debconf setting, you would
> expect that to persist. In fact, if one changes a Debconf setting
> manually, I'd expect it to override local settings.... that's what
> pushing settings is all about.
Then use something other than Debconf. Local settings are NOT to be
overridden.
--
Steve Langasek
postmodern programmer
| |
| Don Armstrong 2004-04-24, 3:34 pm |
| On Wed, 21 Apr 2004, Steve Langasek wrote:
> And, as Debconf Is Not A Registry, most questions that are under
> debconf control should give preference to the already configured
> local settings over anything that would come from LDAP.
Assuming the local settings have actually been configured.
If they're identical to the previous debconf settings and have not
been modified by the local administrator, I see no reason why you
could not change settings via debconf. In fact, I'd suggest that such
functionality is optimal, because it is what allows you to reconfigure
packages using debconf.
In other words, we should try to allow the largest functionality
possible with debconf whilst satisfying the requirements of 10.7.3.
Don Armstrong
--
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
-- Antoine de Saint-Exupe'ry, Terres des Hommes
http://www.donarmstrong.com
http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Denis Barbier 2004-04-24, 5:33 pm |
| On Sat, Apr 24, 2004 at 12:14:31PM -0700, Don Armstrong wrote:
> On Wed, 21 Apr 2004, Steve Langasek wrote:
>
> Assuming the local settings have actually been configured.
>
> If they're identical to the previous debconf settings and have not
> been modified by the local administrator, I see no reason why you
> could not change settings via debconf.
[...]
When a package is reconfigured, the new debconf settings and current
configuration files are available, but previous debconf settings are
not and you cannot determine that there have been no local changes.
Denis
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2004-04-24, 6:34 pm |
| On Sat, 24 Apr 2004, Denis Barbier wrote:
> When a package is reconfigured, the new debconf settings and current
> configuration files are available, but previous debconf settings are
> not and you cannot determine that there have been no local changes.
While the former is true[1], the latter is not. See, for example, how
xserver-xfree86 deals (perhaps suboptimally) with this situation.
It's not all that difficult to determine whether a file has been
modified by the user or not. [Well, assuming the user actually makes a
change to the file... but you'd have the same problems with
conffiles.]
Don Armstrong
1: I'm not as familiar with debconf internals as I could be, so there
might be some method to determine the previous values... I'm just not
aware of it.
--
Clothes make the man. Naked people have little or no influence on
society.
-- Mark Twain
http://www.donarmstrong.com
http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2004-04-25, 2:33 am |
| On Sat, 24 Apr 2004 14:43:25 -0700, Don Armstrong <don@donarmstrong.com> said:
> On Sat, 24 Apr 2004, Denis Barbier wrote:
[vbcol=seagreen]
> While the former is true[1], the latter is not. See, for example,
> how xserver-xfree86 deals (perhaps suboptimally) with this
> situation.
> It's not all that difficult to determine whether a file has been
> modified by the user or not. [Well, assuming the user actually makes
> a change to the file... but you'd have the same problems with
conffiles.>
With conffiles, there is a record of the old versions md5sum.
Of course, ucf is designed for situations like this; you can just use
the debconf db to construct a file, and use ucf to ask the user iff
the user has made any changes.
manoj
--
Small is beautiful.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tollef Fog Heen 2004-04-25, 4:33 am |
| * Andreas Metzler
| Christian Ramseyer <rc@networkz.ch> wrote:
| [...]
| > This is exactly my case. After FAI installation, i would like to
| > reconfigure some packages, and i thought that i could just edit the
| > debconf database and the do a dpkg-reconfigure -f noninteractive.
| [...]
|
| Well. It will not work for packages that use debconf to manage a
| configuration file and do this properly by parsing the configuration
| file and syncing its values into the debconf-db.
Sure it would; the debconf db would just have to be read-only, like an
LDAP tree.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Denis Barbier 2004-04-27, 2:33 am |
| On Sat, Apr 24, 2004 at 02:43:25PM -0700, Don Armstrong wrote:
> On Sat, 24 Apr 2004, Denis Barbier wrote:
>
> While the former is true[1], the latter is not. See, for example, how
> xserver-xfree86 deals (perhaps suboptimally) with this situation.
>
> It's not all that difficult to determine whether a file has been
> modified by the user or not. [Well, assuming the user actually makes a
> change to the file... but you'd have the same problems with
> conffiles.]
Consider for instance the locales package, can you please explain how
local changes in /etc/locale.gen can be preserved while reconfiguring
it in noninteractive mode?
I would really like to learn how to do it, but honestly I doubt that
this is doable, e.g. debconf database might have been removed, in
which case /etc/locale.gen must of course not be cleared out.
Denis
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2004-04-27, 3:33 am |
| Just to be clear, I haven't (yet) implemented the below, but I've
thought about it a little bit... [Manoj and others have much more
experience with debconf and configuration files than I do, so cum
grano solis.
On Tue, 27 Apr 2004, Denis Barbier wrote:
> Consider for instance the locales package, can you please explain
> how local changes in /etc/locale.gen can be preserved while
> reconfiguring it in noninteractive mode?
Has /etc/locale.gen been modified since it was last generated (check
md5sum within the config file)[1]?
Yes:
Use ucf or similar for prompting from the autogenerated files
If non-interactive, do nothing. (Presumably ucf knows how
we're being run)
No:
Reconfigure /etc/locale.gen using debconf settings
[Whatever is done, the # XXX GENERATED XXX probably needs to
go... modifying the file without seeing that line isn't cause for the
admin's changes to go away.[2]]
It probably would be nice if someone would generalize this (part of
ucf?) and make it so that it's easy for the admin to put a file back
under debconf control as well.
Don Armstrong
1: I'd imagine something like a last line with # MD5SUM: blah; and
then the md5sum generated with the # MD5SUM: line missing would
suffice. That way, either changing the file, or removing the MD5SUM
would be enough to let you know that the user had done something
locally. (In effect, the same thing that dpkg does for conffiles.)
--
UF: What's your favourite coffee blend?
PD: Dark Crude with heavy water. You are understandink? "If geiger
counter does not click, the coffee, she is just not thick."
http://www.donarmstrong.com
http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2004-04-27, 3:33 am |
| On Mon, 26 Apr 2004 23:45:53 -0700, Don Armstrong <don@donarmstrong.com> said:
> It probably would be nice if someone would generalize this (part of
> ucf?) and make it so that it's easy for the admin to put a file back
> under debconf control as well.
I am afraid I do not follow. Could you please explain what
part of ucf needs be generalized? From what I could see, there is
nothing that you wanted that icf does not already do, so I must be
missing something.
manoj
--
We gave you an atomic bomb, what do you want, mermaids? Rabi to the
Atomic Energy Commission
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frank Küster 2004-04-27, 4:34 am |
| barbier@linuxfr.org (Denis Barbier) wrote:
> Consider for instance the locales package, can you please explain how
> local changes in /etc/locale.gen can be preserved while reconfiguring
> it in noninteractive mode?
Where's the problem? This file should be parseable really easy. It
consists only of=20
a) comments (marked by ^[[:blank:]]*#) and empty lines
b) lines with pairs of entries
For each non-comment entry, one locale needs to be generated. You just
have to grep for the lines your package knows about, db_set them as
default, and offer them to the user in interactive mode (or just keep
them in noninteractive). User's changes through the debconf interface
can then be introduced either by deleting or adding the respective
lines, or by adding/removing comment signs.
Don't touch lines that your packages doesn't understand.
I have implemented this for tetex-bin's handling of language.dat in
config/postinst recently.
Regards, Frank
--=20
Frank K=FCster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
| |
| Branden Robinson 2004-04-28, 7:34 pm |
| | |
| Denis Barbier 2004-04-29, 2:34 am |
| On Mon, Apr 26, 2004 at 11:45:53PM -0700, Don Armstrong wrote:
> Just to be clear, I haven't (yet) implemented the below, but I've
> thought about it a little bit... [Manoj and others have much more
> experience with debconf and configuration files than I do, so cum
> grano solis.
>
> On Tue, 27 Apr 2004, Denis Barbier wrote:
>
> Has /etc/locale.gen been modified since it was last generated (check
> md5sum within the config file)[1]?
> Yes:
> Use ucf or similar for prompting from the autogenerated files
> If non-interactive, do nothing. (Presumably ucf knows how
> we're being run)
> No:
> Reconfigure /etc/locale.gen using debconf settings
But if debconf database is removed for any reason and /etc/locale.gen
has not been modified, default debconf values will be used, which means
that all locales are removed.
Denis
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Don Armstrong 2004-04-29, 4:34 pm |
| On Thu, 29 Apr 2004, Denis Barbier wrote:
> But if debconf database is removed for any reason and
> /etc/locale.gen has not been modified, default debconf values will
> be used, which means that all locales are removed.
I'd imagine that you should then decide which of the two situations is
worse, and make the default act accordingly.
That is:
1) Read in the values from the config file and set the debconf values
to that.
- or -
2) Set the config file to the default values from the debconf
database.
- or -
3) Punt and ask the user what to do.
[One would imagine that the sane way to do this is to figure out which
of the settings is the most recent, and stick with that... if there
was (is?) a way to distinguish between the times that values in
debconf were selected, that would be quite usefull in this situation.]
But regardless, if the user has modified the file at all their
decision needs to be respected... [these # XXX GENERATED XXX lines
need to go.]
Don Armstrong
--
Any excuse will serve a tyrant.
-- Aesop
http://www.donarmstrong.com
http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|