Re: Announcing debconf, configuration management for debian
Previously Joey Hess wrote: Not really. I named it dpkg-reconfigure for a reason. :-) Have you thought about how you want to integrate it? I've been looking into that a bit and it's not trivial. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpTAyzSjrEhY.pgp Description: PGP signature
Re: Announcing debconf, configuration management for debian
On Mon, Sep 20, 1999 at 02:57:42PM -0600, Scott Barker wrote: dpkg -i package dpkg-reconfigure you could just run: dpkg -i --reconfigure package I'm probably thinking too far ahead right now, though... Why would you install the package (which presumably includes configuration) and then immediately reconfigure it? Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Announcing debconf, configuration management for debian
On Tue, Sep 21, 1999 at 11:02:58AM +1000, Hamish Moffatt wrote: On Mon, Sep 20, 1999 at 02:57:42PM -0600, Scott Barker wrote: dpkg -i package dpkg-reconfigure you could just run: dpkg -i --reconfigure package I'm probably thinking too far ahead right now, though... Why would you install the package (which presumably includes configuration) and then immediately reconfigure it? The whole purpose of Wichert's spec is to force packages to install with a default configuration, and then reconfigure themselves with data from the database after installation. Whether questions are (all) asked before or after installation is a secondary point -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org There are three kinds of people in this world: those who can count and those who can't.
Re: Announcing debconf, configuration management for debian
Aaron Van Couwenberghe wrote: The whole purpose of Wichert's spec is to force packages to install with a default configuration, and then reconfigure themselves with data from the database after installation. Whether questions are (all) asked before or after installation is a secondary point Er not really. The spec makes that possible, but it's hardly the entire goal. Make note of the large amount of effort it goes to to allow you to configure a package *before* installing it as well. -- see shy jo
Re: Announcing debconf, configuration management for debian
On Tue, Sep 21, 1999 at 11:02:58AM +1000, Hamish Moffatt wrote: Why would you install the package (which presumably includes configuration) and then immediately reconfigure it? You upgrade a package, and it gets installed with your previous configuration, and you want to change that configuration. dpkg --configure simply re-runs the postinstall script, which (assuming debconf was used) would simply reconfigure using the previous configuration again. -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] Do infants have as much fun in infancy as adults do in adultery? - ???
Re: Announcing debconf, configuration management for debian
Joey Hess [EMAIL PROTECTED] writes: Steve Greenland wrote: I've read (or at least skimmed) the tutorial you posted, and it looks like the various configuration variables are associated with a package via the template foo/variable. What about variables that are logically shared between packages, such as the default directory for the webservers, or news server name, and such. Is it acceptable for the group of affected maintainers to use the virtual package name as the variable package name? Or would some other way be better? I think we'll eventually let the policy group deal with this. For now there really arn't any rules, just common sense. Yes, I think it's acceptable to use virtual package names. The two packages I have now that share a variable name and slrn and slrnpull, they use news/server, which isn't exactly mapped to a virtual Presumably variable names can have more than one / in them ? If so, it might be worth calling such variables something like: shared/news/server to avoid name space pollution, and to emphasise the fact that there is not a package called ``news'' (virtual or otherwise). Cheers, Phil.
Re: Announcing debconf, configuration management for debian
Philip Hands wrote: Presumably variable names can have more than one / in them ? Yes. If so, it might be worth calling such variables something like: shared/news/server to avoid name space pollution, and to emphasise the fact that there is not a package called ``news'' (virtual or otherwise). Hm, I like that idea. I've written up some preliminary specs on managing the namespace, and that is part of it. -- see shy jo
Re: Announcing debconf, configuration management for debian
Scott Barker wrote: 2) I think I presented this suggestion backwards. According to debconf's docs, a user will be prompted for the answer to a question only if they haven't already answered that question, and only new questions will be presented. I'm suggesting there be a way for a user to over-ride this behaviour and completely reconfigure a package if they want. Am I still missing something in the docs? Is this already possible? It's now possible in two ways. First, there is the dpkg-reconfigure program, which you pass a package name, and it lets you see all the questions again. Secondly, it's now possible to configure debconf to show all questions over and over every time, even if you've already ansered them. 3) I see I missed the substitution capability during my first read of the docs. Sorry about that. But the rest of this suggestion is still valid, in that I'm looking for a way to repackage a package with whatever new defaults I want. Again, this may not be related directly to debconf, but perhaps needs to be implemented in dpkg-repack. dpkg-repack couldn't currently handle this, and I'd have to modify it to know about debconf for it to be able to. A better approach, perhaps, will be to use the remote database capabilities of debconf to just pull settings off the old system when you install a package on the new one. Of course, that's all vaporware at this point. -- see shy jo
Re: Announcing debconf, configuration management for debian
On Mon, Sep 20, 1999 at 01:23:50PM -0700, Joey Hess wrote: It's now possible in two ways. First, there is the dpkg-reconfigure program, which you pass a package name, and it lets you see all the questions again. Excellent. Hopefully if debconf gets folded into the base system, dpkg itself will be able to run this directly, rather than it be an extra step for the user. For example, instead of running (manually, or through apt): dpkg -i package dpkg-reconfigure you could just run: dpkg -i --reconfigure package I'm probably thinking too far ahead right now, though... dpkg-repack couldn't currently handle this, and I'd have to modify it to know about debconf for it to be able to. A better approach, perhaps, will be to use the remote database capabilities of debconf to just pull settings off the old system when you install a package on the new one. Of course, that's all vaporware at this point. I guess I'm just too eager to roll this out in my labs, and I want that vaporware void filled :) How do you feel about moving the template file out of the debian/ control structure, and into the filesystem? If it was /etc/debconf/package instead of debian/templates, dpkg-repack could handle it (and I could start repackaging packages for use in my labs). I don't mean to be pushy, I'm just very excited at the prospect of removing RedHat and replacing it with Debian on all my workstations. -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] I don't pretend to know much about life. You live what you live and most of it doesn't change much from one day to the other. And then some days it just confounds you with the most amazing left turns... At times the unpredictability can be wonderfully sweet; sometimes pretty weird; and once in a while, too sad to speak about except to yourself. Life's a blind punch; you don't know what's hit you 'til it's too late. Guess you just have to close your eyes, stick you chin out, and take what comes. Otherwise you might duck at the wrong time, and miss everything worth living for. - Brick McKenna, McKenna (written by Gil Grant)
Re: Announcing debconf, configuration management for debian
Scott Barker wrote: Excellent. Hopefully if debconf gets folded into the base system, dpkg itself will be able to run this directly, rather than it be an extra step for the user. For example, instead of running (manually, or through apt): dpkg -i package dpkg-reconfigure you could just run: dpkg -i --reconfigure package I'm probably thinking too far ahead right now, though... Not really. I named it dpkg-reconfigure for a reason. :-) How do you feel about moving the template file out of the debian/ control structure, and into the filesystem? If it was /etc/debconf/package instead of debian/templates, dpkg-repack could handle it (and I could start repackaging packages for use in my labs). Oh, that's not the problem. Dpkg-repack should pick up that file fine. What it won't pick up is the actual answers you've given to the questions, which are stored in some debconf db somewhere. -- see shy jo
Re: Announcing debconf, configuration management for debian
On Mon, Sep 20, 1999 at 02:12:06PM -0700, Joey Hess wrote: Not really. I named it dpkg-reconfigure for a reason. :-) Excellent! :) Oh, that's not the problem. Dpkg-repack should pick up that file fine. What it won't pick up is the actual answers you've given to the questions, which are stored in some debconf db somewhere. It's probably anathema to suggest, but what if there was a utility that could export the data from the debconf db back into the template file? I know that would be a terrible hack, and would fiddle with the dpkg files, which we're not supposed to do, but if the only purpose is for an administrator to be able to use dpkg-repack, I think it should be ok. -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] At Group L, Stoffel oversees six first-rate programmers, a managerial challenge roughly comparable to herding cats. - The Washington Post Magazine, June 9, 1985
Re: Announcing debconf, configuration management for debian
I've sent this to the debian-devel list because I've tried to add some clarification to my suggestions, in case they were unclear to others (it seems they may have been). Note that none of my suggestions are in any way negative criticisms. debconf looks incredibly useful as it is, and I just had some thoughts I wanted to share. So, let me clarify my suggestions: 1) This was a suggestion relating to package management (through dpkg, only indirectly to debconf). I'm suggesting a ConfigScript parameter in the package control file, so that debconf's hacks (Joey's term) are not necessary. This suggestion was aimed at dpkg more than debconf. 2) I think I presented this suggestion backwards. According to debconf's docs, a user will be prompted for the answer to a question only if they haven't already answered that question, and only new questions will be presented. I'm suggesting there be a way for a user to over-ride this behaviour and completely reconfigure a package if they want. Am I still missing something in the docs? Is this already possible? 3) I see I missed the substitution capability during my first read of the docs. Sorry about that. But the rest of this suggestion is still valid, in that I'm looking for a way to repackage a package with whatever new defaults I want. Again, this may not be related directly to debconf, but perhaps needs to be implemented in dpkg-repack. My apologies for the lack of clarity in my original email. I hope I have made my suggestions more clear now. Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml I didn't follow the URL to see if this is a joke, but if it is not, you do not know what powers of restraint it requires to stay away from THIS fish hook. Hey, don't knock it :) It's been working, and I've been meeting people. -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] All the world's a stage and most of us are desperately unrehearsed. - Sean O'Casey
Re: Announcing debconf, configuration management for debian
Branden Robinson wrote: Thanks again, Joey. I look forward to migrating XFree86 to debconf (won't happen for -1, but I'm hoping to tackle FHS-compliance and this for -2). Err, can you please wait for this until a) debconf has been accepted and b) there will be proper support for it and c) proper documentation. disclaimer No, I haven't looked at it yet, but I appreciate it. /disclaimer Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists.
Re: Announcing debconf, configuration management for debian
On Sun, Sep 19, 1999 at 12:20:39PM +0200, Martin Schulze wrote: Branden Robinson wrote: Thanks again, Joey. I look forward to migrating XFree86 to debconf (won't happen for -1, but I'm hoping to tackle FHS-compliance and this for -2). Err, can you please wait for this until a) debconf has been accepted and b) there will be proper support for it and c) proper documentation. Hmm, okay. It's not like I have anything else I need to do with the X packages, anyway. You know, no bugs to fix, stuff like that. -- G. Branden Robinson |Kissing girls is a goodness. It is a Debian GNU/Linux |growing closer. It beats the hell out [EMAIL PROTECTED] |of card games. cartoon.ecn.purdue.edu/~branden/ |-- Robert Heinlein pgpbjExs6QBSi.pgp Description: PGP signature
Re: Announcing debconf, configuration management for debian
On Sun, Sep 19, 1999 at 01:16:23PM -0400, Branden Robinson wrote: On Sun, Sep 19, 1999 at 12:20:39PM +0200, Martin Schulze wrote: Branden Robinson wrote: Thanks again, Joey. I look forward to migrating XFree86 to debconf (won't happen for -1, but I'm hoping to tackle FHS-compliance and this for -2). Err, can you please wait for this until a) debconf has been accepted and b) there will be proper support for it and c) proper documentation. Hmm, okay. It should be at least in the Debian ftp archive, I think :) It's not like I have anything else I need to do with the X packages, anyway. You know, no bugs to fix, stuff like that. Oh. If you are bored, finish the Hurd port of X. *grin* Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Announcing debconf, configuration management for debian
[ announce for debconf skipped ] Is i18n going to be supported by debconf? If yes, how? Thanks, -- Mike (who thinks i18n should be considered from the very beginning)
Re: Announcing debconf, configuration management for debian
On 17-Sep-99, 13:23 (CDT), Joey Hess [EMAIL PROTECTED] wrote: This is a bit long, so I'll summarize: Debconf is a tool that packages can use to ask questions when they are installed. It allows various frontends, from dialog, to gtk to web pages to be used, and it also allows for non-interactive package installs, and allows packages to ask questions all at once, before any of them are even installed. Nice job, Joey. I've read (or at least skimmed) the tutorial you posted, and it looks like the various configuration variables are associated with a package via the template foo/variable. What about variables that are logically shared between packages, such as the default directory for the webservers, or news server name, and such. Is it acceptable for the group of affected maintainers to use the virtual package name as the variable package name? Or would some other way be better? -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: Announcing debconf, configuration management for debian
Michael Sobolev wrote: Is i18n going to be supported by debconf? If yes, how? Well Wichert and I have talked about this. One nice thing about debconf is it separates out nearly all translatable text from the postinst and configure script into it's template file. So it merely becomes a question of adding translations to that file. The file is formatted similarly to a package's control file, and should be extensible enough so we can embed translated text in it in a variety of ways (what works good for a control file?) -- see shy jo
Re: Announcing debconf, configuration management for debian
Steve Greenland wrote: I've read (or at least skimmed) the tutorial you posted, and it looks like the various configuration variables are associated with a package via the template foo/variable. What about variables that are logically shared between packages, such as the default directory for the webservers, or news server name, and such. Is it acceptable for the group of affected maintainers to use the virtual package name as the variable package name? Or would some other way be better? I think we'll eventually let the policy group deal with this. For now there really arn't any rules, just common sense. Yes, I think it's acceptable to use virtual package names. The two packages I have now that share a variable name and slrn and slrnpull, they use news/server, which isn't exactly mapped to a virtual package name, since slrn and slrnpull don't share a virtual package name. -- see shy jo
Re: Announcing debconf, configuration management for debian
Well Wichert and I have talked about this. One nice thing about debconf is it separates out nearly all translatable text from the postinst and configure script into it's template file. So it merely becomes a question of adding translations to that file. The file is formatted similarly to a package's control file, and should be extensible enough so we can embed translated text in it in a variety of ways (what works good for a control file?) I don't know about debconf, but it would be great if you can integrate it with gettext... You would just need to set the textdomain and call gettext (included in libc6) for each message.
Re: demo vs. real package: FYI (was Re: Announcing debconf, configuration management for debian)
On Fri, Sep 17, 1999 at 02:45:32PM -0400, Raul Miller wrote: FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. do they automatically set up sash as root's shell? craig -- craig sanders
Re: Announcing debconf, configuration management for debian
Le Fri, Sep 17, 1999 at 11:23:36AM -0700, Joey Hess écrivait: This is a bit long, so I'll summarize: Debconf is a tool that packages can use to ask questions when they are installed. It allows various frontends, from dialog, to gtk to web pages to be used, and it also allows for non-interactive package installs, and allows packages to ask questions all at once, before any of them are even installed. I did not yet check/test your work but I'm sure that it's great ! I wonder if you think that debconf is good/mature enough to be used for potato. If yes, how many packages are interactive in their postinst ? If debconf is working well and if we can push it into base then I'm willing to open QA tasks that would ask to correct all interactive packages to use debconf ... Imagine how great it could be if we could say that potato can install itself if you want ! Later we may even modify the policy to forbid interactivity in postinst unless debconf is used ... Cheers, -- Raphaël Hertzog -=- http://tux.u-strasbg.fr/~raphael/ pub CDs Debian : http://tux.u-strasbg.fr/~raphael/debian/#cd /pub
Re: Announcing debconf, configuration management for debian
Raphael Hertzog wrote: I did not yet check/test your work but I'm sure that it's great ! I wonder if you think that debconf is good/mature enough to be used for potato. Well I've been using it for about a month for just a couple of packages. I will porbably convert my packages to use it once I upload it to unstable. As for everyone else, that's your decision to make.. I can't claim it's mature yet. If yes, how many packages are interactive in their postinst ? 10%? Just a guess. I did a fresh debian install and picked one of the larger profiles, and only about 21 packages out of that profile did any prompting. (Results in /usr/share/debconf/packages-that-prompt.) If debconf is working well and if we can push it into base then I'm willing to open QA tasks that would ask to correct all interactive packages to use debconf ... Imagine how great it could be if we could say that potato can install itself if you want ! Later we may even modify the policy to forbid interactivity in postinst unless debconf is used ... Both things would be great, but let's let it prove itself a little bit first. We don't want to rush things, and we want to make sure it really does meet everyone's needs. The timing of this release of debconf isn't the best, I know, but I was only able to start work on it when VA hired me. :-) -- see shy jo
Re: Announcing debconf, configuration management for debian
Joey Hess wrote: 10%? Just a guess. I did a fresh debian install and picked one of the larger profiles, and only about 21 packages out of that profile did any prompting. (Results in /usr/share/debconf/packages-that-prompt.) Er, there should be a 'doc' in that path. -- see shy jo
Re: Announcing debconf, configuration management for debian
Another question -- I realize the proposed API has been out for a while, but is it possible that the TEXT command could be modified to take a priority? There are probably notifications that the maintainer scripts could display which some people would be interested in but many would not, and being able to filter them would be nice. Daniel -- It is hard to think of anything less sentient than a pumpkin. -- Terry Pratchett, _Witches Abroad_
Re: Announcing debconf, configuration management for debian
Daniel Burrows wrote: Another question -- I realize the proposed API has been out for a while, but is it possible that the TEXT command could be modified to take a priority? Actually, debconf uses a variation on the prposed API, that makes text just be a variety of ui element, like a boolean element or a string element. So there is no text command per se. (And so text does get a priority). You can read the modified debconf api in /usr/doc/debconf/spec/ (I just modified 2 of the web pages) Wichert's been really slow commenting on this, but it makes a lot more sense. -- see shy jo
Re: Announcing debconf, configuration management for debian
On Fri, Sep 17, 1999 at 02:11:20PM -0700, Joey Hess wrote: Have you looked at debconf at all? Because.. Scott Barker wrote: Of course not; people are, sadly, always trying to redesign things they don't even understand. I, for one, am delighted to see this tool come to light after years of design and discussion. Many thanks for being the one who actually implemented it, Joey! I suspect that, once Debian has gotten migrated to it, this will represent a quantum leap forward for us, and ultimately, we'll see the highest form of flattery as other distros borrow it and hack it up for their own purposes. At least a couple will probably try to violate the GPL in the process. Debian has long had the best packaging system of any Linux distribution (though not the easiest to use from the *developer's* standpoint, which is dpkg is so widely slandered as inferior to rpm -- and yet, between debhelper, Doogie's Build System, lintian, and some good documentation, even those objections can be soundly squashed); now we will have the best configuration system as well. Thanks again, Joey. I look forward to migrating XFree86 to debconf (won't happen for -1, but I'm hoping to tackle FHS-compliance and this for -2). -- G. Branden Robinson | It was a typical net.exercise -- a Debian GNU/Linux | screaming mob pounding on a greasy spot [EMAIL PROTECTED] | on the pavement, where used to lie the cartoon.ecn.purdue.edu/~branden/ | carcass of a dead horse. pgpN5Vd5AtYlf.pgp Description: PGP signature
Re: Announcing debconf, configuration management for debian
On Fri, Sep 17, 1999 at 02:11:20PM -0700, Joey Hess wrote: Have you looked at debconf at all? Because.. Scott Barker wrote: 1) Separate interactive and non-interactive installation scripts. I suggest that the current debian install scripts should contain *only* non-interative functionality, such as running ldconfig, update-rc.d, etc. *All* interactive functionality should be moved into a separate config script. This is what debconf does. My reading of it was that you use the debconf functions from within the post-install script. I'm talking about a completely new functionality for the packaging system, where a config script is defined, and is not the post-install script. I will check again, in case I missed something. -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] Technology is a way of organizing the universe so that man doesn't have to experience it. - Max Frisch
Re: Announcing debconf, configuration management for debian
On Sat, Sep 18, 1999 at 02:13:26PM -0400, Branden Robinson wrote: On Fri, Sep 17, 1999 at 02:11:20PM -0700, Joey Hess wrote: Have you looked at debconf at all? Because.. Scott Barker wrote: Of course not; people are, sadly, always trying to redesign things they don't even understand. Not even a dozen messages into this thread, and already the usual user-bashing begins. This is one of Debian's biggest problems, IMHO. The mailing lists are very hostile, not only to users, but also between developers. For your information, I understand just fine. As near as I can tell, debconf needs to be run in the post-install scripts, because there is not yet any functionality within the packaging system to define a separate config script. That extra functionality is what I'm looking for, and it will have to be a joint effort between debconf and dpkg developers. I did not in any way intend to belittle Joey's efforts. I am extremely pleased that debconf has been released, and am anxiously awaiting it's evolution, so that I may deploy it in my University labs and get rid of RedHat. -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] By necessity, by proclivity, and by delight, we all quote. In fact, it is as difficult to appropriate the thoughts of others as it is to invent. - Ralph Waldo Emerson
Re: Announcing debconf, configuration management for debian
Scott Barker wrote: My reading of it was that you use the debconf functions from within the post-install script. I'm talking about a completely new functionality for the packaging system, where a config script is defined, and is not the post-install script. I will check again, in case I missed something. The introduction I posted is short on many details. They are all explained in the debconf tutorial, which I will append to this message. Be assurred, a config script is defined just like you hoped. Introduction This is a guide to using debconf with your packages, aimed at a Debian developer. So, what is debconf? To save you reading the spec (http://www.debian.org/~wakkerma/config6/), debconf is a backend database, with a frontend that talks to it and presents an interface to the user. There can be many different types of frontends, from plain text to a web frontend. The frontend also talks to a special config script in the control section of a debian package, and it can talk to postinst scripts and other scripts as well, all using a special protocol. These scripts tell the frontend what values they need from the database, and the frontend asks the user questions to get those values if they arn't set. Debconf should be used whenever your package needs to output something to the user, or ask a question of the user. I'll assume you already have a package that does this and you want to convert it to use debconf. Getting started --- First, your package must depend on debconf (or pre-depend on it if it uses debconf in its preinst). This is necessary since debconf isn't part of the base system. The first thing to do is look at your postinst, plus any program your postinst calls (like a packageconfig program), plus your preinst, and even your prerm and postrm. Take note of all output they can generate and all input they prompt the user for. All this output and input must be eliminated for your package to use debconf. (Output to stderr can be left as is.) For example, a hypothetical package foo has the following postinst: #!/bin/sh -e echo -n Do you like debian? [yn] read like case $like in n*|N*) echo Poor misguided one. Why are you installing this package, then? /etc/init.d/subliminal_messages start I like debian. ;; esac It's clear that it asks a question and sometimes outputs a message. We will need to use debconf to do both. The Templates file --- Start writing a debian/templates file. Each time you find a piece of output or a question, add it to the file as a new template. The format of this file is simple and quite similar to a Debian control file: Template: packagename/something Type: select,string,boolean,note,text Default: an optional default value Description: Blah blah blah? Blah blah blah. Blah blah. Blah blah blah. Blah blah? Blah blah blah. Blah blah. Blah blah blah. Blah blah. . Blah blah blah. Blah blah. Blah blah blah. Blah blah. Blah blah blah. Blah blah. next template here A short description of the data types: string Holds any arbitrary string of data. boolean Holds true or false. select Holds one of a finite number of possible values. These values must be specified in a field named Choices:. Separate the possible values with commas and spaces, like this: Choices: yes, no, maybe note This template is a note that can be displayed to the user. As opposed to text, it is something important, that the user really should see. If debconf is not running interactively, it might be saved to a log file or mailbox for them to see later. text This template is a scrap of text that can be displayed to the user. Following laong in our example, we create a templates file with two templates in it: Template: foo/like_debian Type: boolean Description: Do you like Debian? We'd like to know if you like the Debian GNU/Linus system. Template: foo/why_debian_is_great Type: note Description: Poor misguided one. Why are you installing this package, then? Debian is great. As you continue using Debian, we hope you will discover the error in your ways. The Config Script - Next, decide what order the questions should be asked and the messages to the user should be displayed, figure out what tests you'll make before asking the questions and displaying the messages, and start writing a debian/config file to ask and display them. Depending on what language you choose to write debian/config in, you have some choices about how to communicate with the frontend: shell script: You can source /usr/share/debconf/confmodule.sh, which will make a number of shell functions available to you. Each shell function corresponds to a command in the protocol (with db_ prefixed to its name). You pass parameters to it and get a result back in the
Re: Announcing debconf, configuration management for debian
Scott Barker wrote: For your information, I understand just fine. As near as I can tell, debconf needs to be run in the post-install scripts, because there is not yet any functionality within the packaging system to define a separate config script. That extra functionality is what I'm looking for, and it will have to be a joint effort between debconf and dpkg developers. Actually, I didn't have to modify dpkg at all to add the config script. I use some pretty disturbing hacks to make sure the config script is run even though dpkg doesn't know about it. But luckily all these hacks can be done away with if/when dpkg is modified to know about the config script. -- see shy jo
Re: Announcing debconf, configuration management for debian
On Sat, Sep 18, 1999 at 12:50:57PM -0600, Scott Barker wrote: Not even a dozen messages into this thread, and already the usual user-bashing begins. I wasn't bashing a user, I was bashing people who levelled criticisms of debconf before it's even been out 24 hours, and more to the point, before they've taken a close look at it. Joey probably doesn't need me to defend him, but I understand that he's put quite a bit of time into debconf over the past few months, and fellow developers making ignorant remarks about his work probably doesn't give him much of a feeling of reward. This is one of Debian's biggest problems, IMHO. The mailing lists are very hostile, not only to users, but also between developers. Often, this happens when some developer runs his mouth off, pretending to knowledge he doesn't possess. In such cases, it's quite right to correct them, but the level of courtesy to be used depends on several factors, mostly how desperately they cling to their ignorance. The clue bat has swung and hit me in the head before, too. The proper way to deal with it is to swallow one's pride, and *learn*. Once one obtains clues, one gets the privilege of wielding the cluebat for oneself. :) For your information, I understand just fine. I won't bother to rebut this, since Joey already did. I did not in any way intend to belittle Joey's efforts. I am extremely pleased that debconf has been released, and am anxiously awaiting it's evolution, so that I may deploy it in my University labs and get rid of RedHat. That, at least, is quite laudable of you. Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml I didn't follow the URL to see if this is a joke, but if it is not, you do not know what powers of restraint it requires to stay away from THIS fish hook. Anyway, if you want to tell me further what an asshole I am, please confine your remarks to private mail. If you want debian-devel to be your audience, then please don't CC me as well. I'm perfectly capable of following the list. -- G. Branden Robinson | Debian GNU/Linux |If existence exists, [EMAIL PROTECTED] |why create a creator? cartoon.ecn.purdue.edu/~branden/ | pgpjGqWW2OJJA.pgp Description: PGP signature
Announcing debconf, configuration management for debian
This is a bit long, so I'll summarize: Debconf is a tool that packages can use to ask questions when they are installed. It allows various frontends, from dialog, to gtk to web pages to be used, and it also allows for non-interactive package installs, and allows packages to ask questions all at once, before any of them are even installed. I'm been working on debconf for about 3 months and it's finally ready to show to people. If you would like to try out debconf, simply add this line to /etc/apt/sources.list: deb http://va.debian.org/~joeyh/ debconf/ There are a few packages in there modified to use debconf. Good examples include slrn, slrnpull, and sash. When you install these packages, they will use dialog (by default) to ask the questions they need to ask. Now, the long story. Currently, if a package needs to prompt the user for input, it just does, using standard input and standard output to communicate with them. A few packages use things like dialog for a user interface, while most use bare-bones textual interfaces. There is little consistency between these interfaces, since they are each written from scratch. They use different methods to indicate default values, different ways to present lists of choices, and even prompt in different ways when the user just needs to hit enter after being shown a message. Many packages ask the user a series of questions with no way to go back to a previous question, or to start over. Most packages that prompt do so in the postinst, and so the user has to baby-sit an install, answering questions as they come up, and then waiting for some more packages to be installed and some more questions to arrive. There is no way to answer all the questions first and then let dpkg install everything unattended, and so installs are a long, drawn out process. Upgrades often take a long time as well, because many packages ask the same questions over and over each time they are installed. Those that don't have to store the user's last response somewhere, and they do this in a variety of different, inconsistent, ways. Moreover, there is no way to simply use default answers for all the questions asked, if you're in a hurry or don't want to be bothered with them, which has historically made the debian install a barrier to new users. The traditional way of asking questions has made some specialized uses of debian harder as well. Many experienced debian users would like to put apt-get update; apt-get upgrade in a cron job, and have their system upgraded periodically to unstable. People working on clusters or other large-scale debian installations can't afford to answer the same questions over and over again on each machine, and have hacked together various ways around this. Finally, several distributions have appeared recently, based on debian but catering to inexperienced users. None of them want the user to see any questions at all when they install, and they have used various hacks to suppress the questions. It seems clear that we need something better to replace the traditional method of querying the user from a maintainer script. It needs to present a consistent user interface to the user. It needs to be able to prioritize questions so non-interactive installs are possible, as well as installs with all questions asked, or only the most important ones. It needs to be able to ask questions only once. And it would be nice if the questions could be stored in a database on a central machine and sent out to other machines in a cluster, so they need only be asked once for a whole cluster. In fall of 1998, Wichert Akkerman came up with a specification for a configuration management system that would address these needs. It was refined on the debian lists over the next several months, and the final specification is at http://www.debian.org/~wakkerma/config6/ . The specification is very flexible, allowing for multiple different back-end databases (using arbitrary database formats from SQL to plain text), that can be layered together and accessed over the network or locally. It also allows for a variety of user interfaces to be presented to the user. The maintainer scripts communicate with the back-end and front-end using a simple language. Debconf is an implementation of this specification. At this point it consists of a variety of front-end user interfaces (plain text similar to the traditional method, dialog based, web, and GTK). It doesn't yet include the flexible back-end database system from the specification. It is already fully usable as a consistent way to configure packages. As it stands now, debconf is usable along-side traditional packages, and packages that use debconf will behave just like normal packages except they use a consistent UI. Debconf also hooks into apt so if you use apt to install several debconf-aware packages at once, the packages will prompt for configuration information _before_ they are installed. An example is in order
Re: Announcing debconf, configuration management for debian
This is great, Joey! Can you show an example of how to use apt-get to *skip* configuration questions altogether? Ben -- Brought to you by the letters W and O and the number 14. It should be illegal to yell 'Y2K' in a crowded economy. Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
demo vs. real package: FYI (was Re: Announcing debconf, configuration management for debian)
On Fri, Sep 17, 1999 at 11:23:36AM -0700, Joey Hess wrote: show to people. If you would like to try out debconf, simply add this line to /etc/apt/sources.list: deb http://va.debian.org/~joeyh/ debconf/ There are a few packages in there modified to use debconf. Good examples include slrn, slrnpull, and sash. When you install these packages, they will use dialog (by default) to ask the questions they need to ask. FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. This simplifies a variety of installation issues. And, given sash's niche as a brute-force-simple program that's supposed to work under very degraded conditions, I think that simple installation (and removal) is important. However, I'm very glad to see debconf, and hope to take a look at it soon. -- Raul
Re: Announcing debconf, configuration management for debian
Ben Gertzfield wrote:
This is great, Joey!
Can you show an example of how to use apt-get to *skip* configuration
questions altogether?
Assumming you have debconf installed, edit /etc/apt/apt.conf, make it look
like this:
// Pre-configure all packages before they are installed.
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --frontend=Base;};
This uses the base frontend, which is a null frontend -- the defaults are
provided for all questions.
An alternative (that may be a better idea) is:
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --priority=critical;};
Which lets you see only the most important questions.
--
see shy jo
Re: demo vs. real package: FYI (was Re: Announcing debconf, configuration management for debian)
Raul Miller wrote: FYI, sash_3.3-5 (which has been sitting in Incoming for the last couple weeks) no longer prompts at postinst time, as the postinst/prerm scripts have been completely redesigned. That's great. The one in the apt repository is of course only a sample. -- see shy jo
Re: Announcing debconf, configuration management for debian
I have some suggestions. Does anyone care to comment? 1) Separate interactive and non-interactive installation scripts. I suggest that the current debian install scripts should contain *only* non-interative functionality, such as running ldconfig, update-rc.d, etc. *All* interactive functionality should be moved into a separate config script. Perhaps a new control field can be added to the debian packaging system. For example: ConfigScript: /usr/sbin/sendmailconfig When dpkg installs a package, it runs the various (non-interactive) scripts as it does now, then if a ConfigScript is defined, it can run that. Or, running the config script can be deferred to a later time, or done before the package is unpacked (of course, the config script would need to be unpacked even if unpacking the rest of the package was deferred). This way, debconf can still be utilized by the ConfigScript, and an extra benefit is that users will have a config program they can easily look up and run to reconfigure any package. In fact, we could have an option like --reconfigure for dpkg so a user could even skip looking up the name of the ConfigScript 2) Add one more level of configuration to debconf: configure new parameters. This would help immensely when upgrading clusters of workstations. An administrator can be notified of all configuration changes when upgrading a package on one workstation, but once the values of those parameters have been set on that workstation, other workstations can inherit them during their upgrades without prompting. 3) Since no database back-end is yet implemented, perhaps we need nothing more than a config file called: /etc/debconf/package In a .deb package, a default configuration could be provided in this file. After debconf runs, all options in this file could be updated based on the user's input. The administrator could then do a dpkg-repack on the package, and use the modified package on the rest of the cluster. While not as convenient as some kind of network-distributed database, this approach would at least allow debconf to be deployed sooner rather than later as part of the base Debian system. The config file mentioned above would probably have to be handled differently than the current definition of config file within a debian package, such that new options can be merged into an existing configuration. Also, it would be nice to be able to embed a bit of perl into the config file, so you could do things like: $lynx_home_page = www.`dnsdomainname`; -- Scott Barker [EMAIL PROTECTED] Linux Consultant http://www.mostlylinux.ab.ca/scott Looking for a husband? Know anyone looking for a husband? Well, I'm looking for a wife. See http://www.mostlylinux.ab.ca/scott/wife.shtml Want a good deal on a personal computer in Calgary, Alberta, Canada? Visit http://www.mostlylinux.ab.ca/scott/computers.shtml [ Unsolicited commercial and junk e-mail will be proof-read for US$100 ] Silent gratitude isn't very much use to anyone. - G.B. Stein
Re: Announcing debconf, configuration management for debian
On Fri, Sep 17, 1999 at 11:57:44AM -0700, Joey Hess was heard to say:
Ben Gertzfield wrote:
This is great, Joey!
Can you show an example of how to use apt-get to *skip* configuration
questions altogether?
Assumming you have debconf installed, edit /etc/apt/apt.conf, make it look
like this:
// Pre-configure all packages before they are installed.
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --frontend=Base;};
This uses the base frontend, which is a null frontend -- the defaults are
provided for all questions.
An alternative (that may be a better idea) is:
DPkg::Pre-Install-Pkgs {dpkg-preconfig --apt --priority=critical;};
Which lets you see only the most important questions.
I've got a question about this. If you use the --frontend=Base approach, is
there any way to mark which packages were installed in this way? I'd
personally like to be able to do this but also to go back later and fix up
configuration for packages which had configure options. Also, are the APIs
designed in a way that guarantees this to work, or will the config options only
be effective if set before the package is installed, or does it depend on the
package maintainer Doing the Right Thing? (I'm still working through Wichert's
proposal, so apologies if it's covered in there..)
Daniel
--
Imagine if every Thursday your shoes exploded if you tied them the usual
way. This happens to us all the time with computers, and nobody thinks of
complaining.
-- Jeff Raskin
Re: Announcing debconf, configuration management for debian
Have you looked at debconf at all? Because.. Scott Barker wrote: 1) Separate interactive and non-interactive installation scripts. I suggest that the current debian install scripts should contain *only* non-interative functionality, such as running ldconfig, update-rc.d, etc. *All* interactive functionality should be moved into a separate config script. This is what debconf does. 2) Add one more level of configuration to debconf: configure new parameters. This would help immensely when upgrading clusters of workstations. An administrator can be notified of all configuration changes when upgrading a package on one workstation, but once the values of those parameters have been set on that workstation, other workstations can inherit them during their upgrades without prompting. This is in the spec, although not yet implemented. -- see shy jo
Re: Announcing debconf, configuration management for debian
Daniel Burrows wrote: I've got a question about this. If you use the --frontend=Base approach, is there any way to mark which packages were installed in this way? No. Though I can see adding it. I'd personally like to be able to do this but also to go back later and fix up configuration for packages which had configure options. One thing debconf lets you do is reconfigure packages after install. Just run dpkg-reconfigure package, and it's as if you're installing it again. Also, are the APIs designed in a way that guarantees this to work, or will the config options only be effective if set before the package is installed, or does it depend on the package maintainer Doing the Right Thing? (I'm still working through Wichert's proposal, so apologies if it's covered in there..) Basically, dpkg-reconfigure has to call the postinst again to make sure any changes you make in your answers to the questions are seen and acted on. The postinst is idempotent, so running it again is really no problem. -- see shy jo
