Re: Debconf problem
Joey Hess [EMAIL PROTECTED] wrote: Frank Küster wrote: Because it isn't true that the previous version didn't use debconf. It just asked the questions totally differently and took an approach that I now would call flawed. But still it gave the users the impression that their ls-R files' permissions are managed by debconf, and probably many thought they were properly managed and didn't do any manual changes. Well, assuming that your debconf questions are different from the ones it asked before, this is the same as not having had questions before. Consider what I've said before to operate on a per-question basis. (In other words, I'm suggesting that you rename your questions and ask the new ones on upgrade from the broken versions of the package.) In the previous mail, I understood you suggested to not at all ask questions on upgrade: , | Your package is being converted from a previous version, which did not | use debconf and did have the files, to a version which does use debconf. | So why ask the question on upgrade from this previous version at all? ` So I'm confused. The parameters passed to the config script can be used to detect the upgrade and not ask any questions or populate the debconf database at all, while leaving debconf asking the question on fresh installs and when reconfigured. Oh, but that seems very hard to do right: The only way to differentiate between an upgrade and reconfigure seems to be the version number of the last installed version. No, in an upgrade, $2 is configure, for a reconfigure $2 is reconfigure. Stupid me, I can't read. But since one could install the package noninteractively, but switch to an interactive frontend before an upgrade, I would have to avoid asking questions for *any* last-installed version number older than the current one (if I decide not to ask and act at all upon upgrade). Only if the noninteractive install ran with DEBCONF_NONINTERACTIVE_SEEN not set to true. Not setting that to true by default is agruably a bug in debconf since it does lead to this edge condition, but it's not an edge case I would worry about dealing with in your package. Okay, thanks - is this variable documented anywhere? Things getting clearer, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debconf problem
Hi Joey, thanks for being patient with me. I promise that I'll write this up (for debconf-devel(7) or the developer's reference or whatever you suggest) once we've sorted this out. Joey Hess [EMAIL PROTECTED] wrote: Does that mean I must use some hackish handmade flags that are reset only at the end of the postinst, and thus indicate whether there was a postinst run after the last config run? No, it means that you're taking the wrong approach to using debconf. I've been trying to point you at tools that will lead to an appropriate solution. Ah, I see. Your package is being converted from a previous version, which did not use debconf and did have the files, to a version which does use debconf. So why ask the question on upgrade from this previous version at all? Because it isn't true that the previous version didn't use debconf. It just asked the questions totally differently and took an approach that I now would call flawed. But still it gave the users the impression that their ls-R files' permissions are managed by debconf, and probably many thought they were properly managed and didn't do any manual changes. Now if I just let the system be as it is, I kind of leave these users alone. But maybe you are right and this is the only solution - we could indicate in NEWS.Debian that everybody who wants debconf management should reconfigure the package. But then, why not ask anyway? The parameters passed to the config script can be used to detect the upgrade and not ask any questions or populate the debconf database at all, while leaving debconf asking the question on fresh installs and when reconfigured. Oh, but that seems very hard to do right: The only way to differentiate between an upgrade and reconfigure seems to be the version number of the last installed version. But since one could install the package noninteractively, but switch to an interactive frontend before an upgrade, I would have to avoid asking questions for *any* last-installed version number older than the current one (if I decide not to ask and act at all upon upgrade). To avoid this, and also detect such upgrades, I have to put the *current* version number into the config script, and only act if the version passed as installed-version is either empty (fresh install), or it matches the hardcoded version current number in the script (reconfigure). And even if I don't forget to update the version number in the config script, what about NMUs? Binary-only NMUs? I hope I'm wrong... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debconf problem
Frank Küster wrote: Because it isn't true that the previous version didn't use debconf. It just asked the questions totally differently and took an approach that I now would call flawed. But still it gave the users the impression that their ls-R files' permissions are managed by debconf, and probably many thought they were properly managed and didn't do any manual changes. Well, assuming that your debconf questions are different from the ones it asked before, this is the same as not having had questions before. Consider what I've said before to operate on a per-question basis. (In other words, I'm suggesting that you rename your questions and ask the new ones on upgrade from the broken versions of the package.) The parameters passed to the config script can be used to detect the upgrade and not ask any questions or populate the debconf database at all, while leaving debconf asking the question on fresh installs and when reconfigured. Oh, but that seems very hard to do right: The only way to differentiate between an upgrade and reconfigure seems to be the version number of the last installed version. No, in an upgrade, $2 is configure, for a reconfigure $2 is reconfigure. But since one could install the package noninteractively, but switch to an interactive frontend before an upgrade, I would have to avoid asking questions for *any* last-installed version number older than the current one (if I decide not to ask and act at all upon upgrade). Only if the noninteractive install ran with DEBCONF_NONINTERACTIVE_SEEN not set to true. Not setting that to true by default is agruably a bug in debconf since it does lead to this edge condition, but it's not an edge case I would worry about dealing with in your package. -- see shy jo signature.asc Description: Digital signature
Re: Debconf problem
Joey Hess [EMAIL PROTECTED] wrote: Frank Küster wrote: I found no way to cleanly solve the problem of - writing the current state into the debconf database, so that noninteractive installs don't change anything - actually reflect changed answers in the system. The config script is passed parameters that you can use to tell if it is an upgrade or a reconfigure and handle these cases appropriatly. Sorry for still being dumb. When it's reconfigure, I have just learned that the config script is run only once, so I need not handle this case specially. But when its an upgrade, it is run twice, and I need to discriminate between the first pass (check existing permission, db_set, question will be asked depending on frontend and priority) and the second pass (no need to check existing permissions, no db_set, question will not be asked). As I read debconf-devel(7), the arguments are the same in both invocations. Does that mean I must use some hackish handmade flags that are reset only at the end of the postinst, and thus indicate whether there was a postinst run after the last config run? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debconf problem
Frank Küster wrote: Sorry for still being dumb. When it's reconfigure, I have just learned that the config script is run only once, so I need not handle this case specially. But when its an upgrade, it is run twice, and I need to discriminate between the first pass (check existing permission, db_set, question will be asked depending on frontend and priority) and the second pass (no need to check existing permissions, no db_set, question will not be asked). As I read debconf-devel(7), the arguments are the same in both invocations. Does that mean I must use some hackish handmade flags that are reset only at the end of the postinst, and thus indicate whether there was a postinst run after the last config run? No, it means that you're taking the wrong approach to using debconf. I've been trying to point you at tools that will lead to an appropriate solution. Your package is being converted from a previous version, which did not use debconf and did have the files, to a version which does use debconf. So why ask the question on upgrade from this previous version at all? The parameters passed to the config script can be used to detect the upgrade and not ask any questions or populate the debconf database at all, while leaving debconf asking the question on fresh installs and when reconfigured. -- see shy jo signature.asc Description: Digital signature
Debconf problem
Hi, I posted this question yesterday on -mentors, but since nobody answered, it seems it isn't as trivial as I had hoped. I have either some fundamental misunderstanding of how debconf or maintainer scripts work, or there is an error in the descriptioin of how debconf-using scripts should handle configuration files. In debconf-devel(7), the section Config file handling under ADVANCED PROGRAMING WITH DEBCONF suggests the following config script: #!/bin/sh CONFIGFILE=/etc/foo.conf set -e . /usr/share/debconf/confmodule # Load config file, if it exists. if [ -e $CONFIGFILE ]; then . $CONFIGFILE || true # Store values from config file into # debconf db. db_set mypackage/foo FOO db_set mypackage/bar BAR fi # Ask questions. db_input medium mypackage/foo || true db_input medium mypackage/bar || true db_go || true However, in case apt-utils is installed, this script will be run twice: Once by dpkg-preconfigure, i.e. in the preinst stage, and once by confmodule when the postinst script sources confmodule. As far as I can see, this will have a confusing effect. Assume the configfile currently contains FOO=true and the local admin wants to change this to FOO=false using dpkg-reconfigure mypackage. This is what is going to happen: - The config script is run and sources $CONFIGFILE, FOO is set to true, mypackage/foo is set to true in the debconf database, too, and the question is asked. The local admin answers to disable foo, and now mypackage/foo is set to false in the database. - The postinst script is run, sources confmodule, which executes config again. config sources the (yet unchanged) $CONFIGFILE, FOO is set to true, and again mypackage/foo is set to true in the debconf database. This time, however, debconf does not ask the question again, so true stays in the database. - The postinst script is reexecuted by debconf, this time it really runs, queries the debconf database, gets the answer true for mypackage/foo, and does *not* change $CONFIGFILE. Pleaase, tell me, where is my mistake? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debconf problem
Frank Küster wrote: However, in case apt-utils is installed, this script will be run twice: Once by dpkg-preconfigure, i.e. in the preinst stage, and once by confmodule when the postinst script sources confmodule. As far as I can see, this will have a confusing effect. Assume the configfile currently contains FOO=true and the local admin wants to change this to FOO=false using dpkg-reconfigure mypackage. This is what is going to happen: dpkg-reconfigure runs the config script exactly once, so the config file is read once, its values are used for defaults to the questions to allow reconfiguration, and are saved to the config file by the postinst. In the case of a fresh installation of the package, or an upgrade from a version before the config file exists, or before a given line is added to the config file, the config script runs the first time, does not override the question from the default in the debconf database because the config file is not present, the user answers the question, the config script runs again similarly but the question is not asked a second time, and the postinst script writes the values into the config file. In the case of an upgrade of the package, the config file exists, the config script runs as you describe but the user is not asked any questions since they have seen them before, and the postinst writes the old values back into the config file. In more complex cases, such as adding a debconf question based on a config file line that already exists in a previous version of the package, you have to add additional code. -- see shy jo signature.asc Description: Digital signature
Re: Debconf problem
Joey Hess [EMAIL PROTECTED] wrote: dpkg-reconfigure runs the config script exactly once, so the config file is read once, its values are used for defaults to the questions to allow reconfiguration, and are saved to the config file by the postinst. Yes, I was wrong about this - it's only run twice upon apt-get install and friends. In more complex cases, such as adding a debconf question based on a config file line that already exists in a previous version of the package, you have to add additional code. Mine is probably a more complex case, but it may be not so uncommon. I only talked about config files because I didn't understand the details even of the simple case, but that is clear now. In the real case, the item that is configured are the permissions of generated files (i.e. files not included in the deb, so dpkg-statoverride cannot be used), the ls-R files of teTeX/tex-common. There existed some debconf questions about this, but the approach we took in sarge was flawed, and therefore we decided to not take over any seen flags. What we try to do is determine which of three ls-R files should be group-writable. Upon a fresh install, they don't exist when config is run, but upon upgrade or dpkg-reconfigure they do exist. Is there any package that does a thing like that? I found no way to cleanly solve the problem of - writing the current state into the debconf database, so that noninteractive installs don't change anything - actually reflect changed answers in the system. The only idea I came up with is to tell the script whether the question has been *just* seen (e.g. with a db_fset mypackage/question justseen after db_go in config, and resetting this flag in the postinst script). But this seems to be an ugly hack. The current code, stripped down to one file, is if [ -r $lsr ] ; then if ls -l $lsr | grep -q ^.w ; then gwrite=true else gwrite=false fi db_set tex-common/managedlsr $gwrite || true fi db_input low tex-common/managedlsr || true db_go And the postinst does db_get tex-common/managedlsr || true if [ $RET = true ]; then test -e $lsr || echo $ls_R_magic $lsr chmod g+w $lsr fi TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debconf problem
Frank Küster wrote: I found no way to cleanly solve the problem of - writing the current state into the debconf database, so that noninteractive installs don't change anything - actually reflect changed answers in the system. The config script is passed parameters that you can use to tell if it is an upgrade or a reconfigure and handle these cases appropriatly. -- see shy jo signature.asc Description: Digital signature
Re: Bug#276306: dpkg -P backuppc fails (debconf problem ?)
Ludovic Drolez [EMAIL PROTECTED] wrote: Frank Küster wrote: Please try to debug by putting a set -x into /var/lib/dpkg/info/backuppc.postrm (or prerm, whatever it is). If it really hangs at db_purge, it may be a bug in debconf. You should know that. Yes, I've alread tried the 'set -x'. That's how I found it was stuck in db_purge... I've tried debconf 1.4.30.5, 1.4.30.8 and 1.4.39. They're all stuck in db_purge, waiting for something from stdin ! Calm down. Start reading. Start with debconf-devel(7). Go to the DEBUGGING section. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Bug#276306: dpkg -P backuppc fails (debconf problem ?)
Frank Küster wrote: Ludovic Drolez [EMAIL PROTECTED] schrieb: The postinst script seems to be stuck in db_purge, a line which was added automatically: The postinst script is not executed upon purging a package. Probably you mean the postrm script? Yes. ... # Automatically added by dh_installdebconf if [ $1 = purge ] [ -e /usr/share/debconf/confmodule ]; then . /usr/share/debconf/confmodule db_purge fi # End automatically added section ... So it may be a bug in dpkg ? Please try to debug by putting a set -x into /var/lib/dpkg/info/backuppc.postrm (or prerm, whatever it is). If it really hangs at db_purge, it may be a bug in debconf. You should know that. Yes, I've alread tried the 'set -x'. That's how I found it was stuck in db_purge... I've tried debconf 1.4.30.5, 1.4.30.8 and 1.4.39. They're all stuck in db_purge, waiting for something from stdin ! -- Ludovic Drolez. http://www.palmopensource.com - The PalmOS Open Source Portal http://www.drolez.com - Personal site - Linux and PalmOS stuff
