Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Hi Petter, hi all, (Sorry I didn't have time to watch your movies yet) This thread turned to be very interesting in the light of the recent discussion on -tetex-maint about TEXMF tree reorganization. Petter Reinholdtsen [EMAIL PROTECTED] wrote: Or even better, ship the defaults in /usr/share/, load them from there and load overrides from /etc/ if a file exist there. If you want the package to have install time defaults, generate the file in /etc/ based on install time input. This way you can handle upgrades gracefully when changing the defaults, without loosing local configuration overrides. Actually that wouldn't be hard for teTeX, since it looks for texmf.cnf at multiple places and reads them all. Even the order is as intended - a file in /etc/texmf would override settings from the file in /usr/share/texmf. However, I don't see how I can handle the fact that there is an unknown number of add-on-TeX-packages that might each provide a snippet for the configuration file. Currently we do this with an update-texmf program that merges the snippets in /etc/texmf/texmf.d/ (ours and from add-on packages) into the effective configuration file below /var. Having three files - ours in /usr/share/texmf/, a package-specific, generated one in /var/lib/texmf with the source files in /etc/texmf/texmf.d/, and the one for the local admin as /etc/texmf/texmf.cnf seems confusing to me. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
[Frank Küster] Actually that wouldn't be hard for teTeX, since it looks for texmf.cnf at multiple places and reads them all. Even the order is as intended - a file in /etc/texmf would override settings from the file in /usr/share/texmf. Very good. Should make it possible to implement a system to remove the questions during upgrades. :) Having three files - ours in /usr/share/texmf/, a package-specific, generated one in /var/lib/texmf with the source files in /etc/texmf/texmf.d/, and the one for the local admin as /etc/texmf/texmf.cnf seems confusing to me. One way to reduce the confusion would be to add references to the other files in the header of each file. This way the people reading the file in /usr/share/, /etc/ or /var/lib/ have a better chance of discovering the other files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Frank Küster wrote: Because one of the changes in the new version was crucial for the function of the program, the postinst script fails to initialize it, and the whole installation process fails. I agree this is the right thing to happen. A package which has been configured is expected to provide its functionality by any packages which Depend: on it, and also by the admin. Also, if you just ignore the error, it'll get lost in dpkg's messages, and the admin will be confused when one of you Depend'ing packages mysteriously fails to configure. BTW: I suspect a lot of packages will fail to configure if you mess up the config enough. Extremely important packages do this too; e.g., lilo, kernel images. It is quite important there: The admin *must* be made aware of the failure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Peter Samuelson [Henning Makholm] Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? 'conffile' is dpkg jargon that has a specific meaning: configuration files that dpkg handles specially w/r/t upgrades and removals. Editing a conffile at install time makes no sense. Of course it would have to be done a preinst time, before dpkg starts unpacking the new version. If you want to edit a configuration file, don't ship it as a conffile - in fact, don't ship it at all. You seem to be missing the entire context of the conversation. Please read back in the thread. -- Henning Makholm What has it got in its pocketses? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
[Peter Samuelson] 'conffile' is dpkg jargon that has a specific meaning: configuration files that dpkg handles specially w/r/t upgrades and removals. Editing a conffile at install time makes no sense. If you want to edit a configuration file, don't ship it as a conffile - in fact, don't ship it at all. Either generate it ex nihilo from a script, or if you feel you need a template, ship the template under another name, to be copied from if the file doesn't already exist. Or even better, ship the defaults in /usr/share/, load them from there and load overrides from /etc/ if a file exist there. If you want the package to have install time defaults, generate the file in /etc/ based on install time input. This way you can handle upgrades gracefully when changing the defaults, without loosing local configuration overrides. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? Of course, see 10.7.3: | These two styles of configuration file handling must not be mixed, for | that way lies madness: dpkg will ask about overwriting the file every | time the package is upgraded. ` This rationale does not apply to the case we are discussing. Why do you think that? There are four versions of the conffile that we have to consider: 1 The version delivered in the old deb 2 The version present on the system before the upgrade 3 The version delivered in the new deb 4 The version produced by the postinst editing action Right before the postinst is run, version 1 has disappeared, 2 is still in its place (we are talking about the situation where the admin refused to accept the changes, and also didn't edit the file), and 3 is available as *.dpkg-new. The postinst script would remove (or rename) version 2 and produce version 4. dpgk does not know about this version, and this is exactly the problem outlined in the policy - or what am I missing? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Peter Samuelson [Henning Makholm] Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? 'conffile' is dpkg jargon that has a specific meaning: configuration files that dpkg handles specially w/r/t upgrades and removals. Editing a conffile at install time makes no sense. Of course it would have to be done a preinst time, before dpkg starts unpacking the new version. This would circumvent the ask again problem, but I think it is still problematic: The admin is shown a diff between the new conffile and the present conffile, but only the unimportant changes are shown, while the important change has already been done by the preinst script. This is confusing - especially if the admin remembers his old file, or if one of the unimportant changes is a change in a comment that says how important the new setting is... If you want to edit a configuration file, don't ship it as a conffile - in fact, don't ship it at all. You seem to be missing the entire context of the conversation. Please read back in the thread. No, I think he simply missed the idea of doing the editing in preinst, just like me - you never mentioned it before. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: In the long run, the user-friendly solution is probably to offer (via a debconf question that defaults to 'yes') to automatically rewrite the conffile to take the change into account. That can only be done if we change our policy with respect to maintainer scripts changing of conffiles; and that I would not want unless something like ucf does is integrated in dpkg. Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? -- Henning Makholm Khanivore is climbing out of its life-support pod.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: In the long run, the user-friendly solution is probably to offer (via a debconf question that defaults to 'yes') to automatically rewrite the conffile to take the change into account. That can only be done if we change our policy with respect to maintainer scripts changing of conffiles; and that I would not want unless something like ucf does is integrated in dpkg. Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? Of course, see 10.7.3: , | The easy way to achieve this behavior is to make the configuration | file a conffile. | [...] | The other way to do it is via the maintainer scripts. | [...] | | These two styles of configuration file handling must not be mixed, for | that way lies madness: dpkg will ask about overwriting the file every | time the package is upgraded. ` Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? Of course, see 10.7.3: | These two styles of configuration file handling must not be mixed, for | that way lies madness: dpkg will ask about overwriting the file every | time the package is upgraded. ` This rationale does not apply to the case we are discussing. -- Henning MakholmDe kan rejse hid og did i verden nok så flot Og er helt fortrolig med alverdens militær
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
[Henning Makholm] Do you mean that every package that offers to edit conffiles based on debconf questions is policy-buggy? 'conffile' is dpkg jargon that has a specific meaning: configuration files that dpkg handles specially w/r/t upgrades and removals. Editing a conffile at install time makes no sense. If you want to edit a configuration file, don't ship it as a conffile - in fact, don't ship it at all. Either generate it ex nihilo from a script, or if you feel you need a template, ship the template under another name, to be copied from if the file doesn't already exist. signature.asc Description: Digital signature
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On 11/1/05, Frank Lichtenheld [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: In my opinion this is not a bug (except if the package is crucial for the system to work and be reachable, like ssh) - the local admin simply has to review the changes to conffiles that dpkg requested, and have a look at NEWS.Debian and changelog.Debian. If these files do not contain enough information to fix the system, then this is a bug, right? But the simple fact that a postinst script fails because a change has been refused isn't - and for sure it is not a serious or grave bug, severities often used when a postinst fails. Opinions? There is one big problem with that scenario that I haven't seen mentioned in this thread yet: If I make the dist-upgrade of a machine from sarge to etch and the dist-upgrade fails right in the middle of the installed 3000 packages I will be severly disappointed to say the least if that didn't happen for a very good reason... That's a fact that often gets lost when discussing such problem from developer to developer that install sid on their machines and update about 30 packages at once. So if it is at all possible to avoid failing the postinst (which of course also means to not break other packages installation as you have pointed out) it should be done. Wouldn't it be better to improve apt so it doesn't abort if a single package fails? It should still be able to continue with independent packages.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Frank Lichtenheld [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: In my opinion this is not a bug (except if the package is crucial for the system to work and be reachable, like ssh) - the local admin simply has to review the changes to conffiles that dpkg requested, and have a look at NEWS.Debian and changelog.Debian. If these files do not contain enough information to fix the system, then this is a bug, right? But the simple fact that a postinst script fails because a change has been refused isn't - and for sure it is not a serious or grave bug, severities often used when a postinst fails. Opinions? There is one big problem with that scenario that I haven't seen mentioned in this thread yet: If I make the dist-upgrade of a machine from sarge to etch and the dist-upgrade fails right in the middle of the installed 3000 packages I will be severly disappointed to say the least if that didn't happen for a very good reason... That's a fact that often gets lost when discussing such problem from developer to developer that install sid on their machines and update about 30 packages at once. Maybe we need a policy (or a change in dpkg's default behavior) for that. One option would be to recommend to take the new version and merge local changes afterwards (but this might severely break more important things, like ssh in an environment where port 22 is blocked...). Or on the other hand, packages that change incompatibly must ensure that they are not installed automatically - however that would mean that every package that build-depends on the changed package would have to change its control file. So if it is at all possible to avoid failing the postinst (which of course also means to not break other packages installation as you have pointed out) it should be done. If it is at all possible in the case of tetex I can't tell, though. I do not see how it could be made possible. Oh, yes, there is one way, and we have even tried to go that route: After the conffile questions have been asked, we check in the postinst script whether some essential entries in ucf-managed configuration files are wrong, and if they are we change the file. But we can't do that for dpkg-managed files, and in any case I don't want to have a 1000 line postinst script because it checks for 30 possibly fatal refused changes... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] These variables can be changed by a configuration file, and some of them *must* be set. Now if a user refuses to accept the change that switches from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer work. You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. Why do you want to deny the sysadmin the opportunity to do the changes himself? He presumably did have a good reason to make the local adaptations he did, and who are you do decree that his preferred method of solution MUST be to redo all of his local adaptations by hand, instead of to make the simple upstream change to one line in the file by hand? -- Henning Makholm It will be useful even at this early stage to review briefly the main features of the universe as they are known today.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] These variables can be changed by a configuration file, and some of them *must* be set. Now if a user refuses to accept the change that switches from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer work. You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. No, of course there is an other way: dpkg offers an option to start a shell (or put itself in the background or whatever) to clear up the situation; or one can simply log in on a different terminal. But if the local admin doesn't want to do that, but delay merging the configuration file, there are only two possibilities: Either he accepts the new maintainer's version, or he refuses it. And the latter choice leads to a failure of the postinst script in some cases. It's only *some* cases; I think in the most important cases, the file isn't dpkg-managed (but ucf-managed), anyway, so we choose to forcibly introduce the variable name changes if the rest of the line was unchanged (or recognizable). But that cannot always be done, and in fact the reason why I decided to ask this is because a user had an old version of a conffile of an other package. The other package depends on tetex, and must recreate its format (reinitialize) when tetex is updated - and made tetex's postinst fail. Why do you want to deny the sysadmin the opportunity to do the changes himself? I don't. All I do is request some support for the view that if he decides to do so, he should in fact do it before filing a bug; and if he files a bug that I can close or downgrade it to non-RC severity. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. No, of course there is an other way: dpkg offers an option to start a shell (or put itself in the background or whatever) to clear up the situation; or one can simply log in on a different terminal. Exactly, but what happens then is 1. User backgrounds dpkg, or switches to another window. 2. User edits the file to take into account the new variable name. 3. User returns to dpkg. 4. User selects the No, I'm happy with my own version as it look now menu option. Your proposal, if I understand you correctly, is to make (4) result in the postinst failing even though the user _has_ taken care of the problem. But if the local admin doesn't want to do that, but delay merging the configuration file, there are only two possibilities: Either he accepts the new maintainer's version, or he refuses it. And the latter choice leads to a failure of the postinst script in some cases. This is not true. If he edits the file himself (but refuses the maintainer's version because accepting it would lead to his own changes being overwritten) things still work fine. Why do you want to deny the sysadmin the opportunity to do the changes himself? I don't. You want the postinst to fail if he does the changes himself rather than abandoning all of his local changes, right? That is _not_ how conffiles are supposed to work. All I do is request some support for the view that if he decides to do so, he should in fact do it before filing a bug; Of course it is not a bug if the package fails because the admin does not properly adjust his conffiles. But it _is_ a bug if the postinst refuses to do its work unless it gets to overwrite the conffile with a pristine upstream version. -- Henning Makholm Wir kommen nun ans Ziel unserer Ausführungen.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. No, of course there is an other way: dpkg offers an option to start a shell (or put itself in the background or whatever) to clear up the situation; or one can simply log in on a different terminal. Exactly, but what happens then is 1. User backgrounds dpkg, or switches to another window. 2. User edits the file to take into account the new variable name. 3. User returns to dpkg. 4. User selects the No, I'm happy with my own version as it look now menu option. Your proposal, if I understand you correctly, is to make (4) result in the postinst failing even though the user _has_ taken care of the problem. You must have misunderstood me. I don't check whether the installed file is the one I expect; I simply run fmtutil --all - and that will fail if he hasn't solved the problem. But if the local admin doesn't want to do that, but delay merging the configuration file, there are only two possibilities: Either he accepts the new maintainer's version, or he refuses it. And the latter choice leads to a failure of the postinst script in some cases. This is not true. It is - with that I meant to edit the file now. If he edits the file himself (but refuses the maintainer's version because accepting it would lead to his own changes being overwritten) things still work fine. Of course they will. In particular, I won't get a bug report and won't have to consider closing or downgrading it, and ask questions on -devel :-) Why do you want to deny the sysadmin the opportunity to do the changes himself? I don't. You want the postinst to fail if he does the changes himself rather than abandoning all of his local changes, right? No, if I have written something like this I must have been insane. All I want to say is: If he does the changes himself bug does it wrong, the fmtutil call (or updmap or whatever) in postinst will fail. But this is in fact a corner case, the usual situation is that the user pressed keep local version without thinking, or simply uses the noninteractive frontend and doesn't bother himself with looking at any *.dpkg-new files before reporting the bug. All I do is request some support for the view that if he decides to do so, he should in fact do it before filing a bug; Of course it is not a bug if the package fails because the admin does not properly adjust his conffiles. So finally there is one person who simply says yes to the question in the first mail, thank you. By the way, I don't think that the answer should be a simple yes: If a failure to configure might cause the system to be inaccessible over the net, the package maintainer has to take care to avoid this (i.e. ask a non-debconfized question in preinst, as glibc does). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
[Frank Küster] assume that an update to a package brings in a changed conffile, and because the local admin had changed the conffile, he is asked, and he refuses to accept the changed version. Because one of the changes in the new version was crucial for the function of the program, the postinst script fails to initialize it, and the whole installation process fails. My proposal to avoid such problem is to implement multilevel configuration, where the package default configuration and the local overrides are stored in separate files, making sure local configuration do not affect changes to the package default, and thus no question is asked during upgrade. I talked a bit about this during debconf5. Have a look at URL:http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-12/06-Writing_Enterprise_Ready_Software-Petter_Reinholdtsen.mpeg and URL:http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-16/12-Debian_Edu_Upgrading_a_Preconfigured_CDD-Petter_Reinholdtsen.mpeg, as well as the slides available from URL:http://wiki.debian.org/?DebConf5Talks. Moving tetex to such mechanism would require some work. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: 4. User selects the No, I'm happy with my own version as it look now menu option. Your proposal, if I understand you correctly, is to make (4) result in the postinst failing even though the user _has_ taken care of the problem. You must have misunderstood me. I don't check whether the installed file is the one I expect; I simply run fmtutil --all - and that will fail if he hasn't solved the problem. Ah. I read your proposal as if you wanted to somehow intercept the user's answer and explicitly bail out from the postinst if the user is asked, and he refuses to accept the changed version. Of course it is not a bug if the package fails because the admin does not properly adjust his conffiles. So finally there is one person who simply says yes to the question in the first mail, thank you. By the way, I don't think that the answer should be a simple yes: If a failure to configure might cause the system to be inaccessible over the net, the package maintainer has to take care to avoid this (i.e. ask a non-debconfized question in preinst, as glibc does). Generally, I think that we depend on the user who has chosen to change a conffile himself to also be able to judge correctly whether a maintainer-supplied change is relevant to him or not. Though this assumption is often wrong, it is the best thing we have in general. It is of course reasonable to be more paranoid than that in situations where failure can impair one's ability to fix things later. In the long run, the user-friendly solution is probably to offer (via a debconf question that defaults to 'yes') to automatically rewrite the conffile to take the change into account. In the case you're presenting here it seems that it ought to be doable by search-and-replace. The offer should only be made if the conffile has actually changed *and* it mentions the old variable names *and* one is upgrading from an older version. -- Henning MakholmWe can hope that this serious deficiency will be remedied in the final version of BibTeX, 1.0, which is expected to appear when the LaTeX 3.0 development is completed.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: In the long run, the user-friendly solution is probably to offer (via a debconf question that defaults to 'yes') to automatically rewrite the conffile to take the change into account. That can only be done if we change our policy with respect to maintainer scripts changing of conffiles; and that I would not want unless something like ucf does is integrated in dpkg. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Petter Reinholdtsen wrote: My proposal to avoid such problem is to implement multilevel configuration, where the package default configuration and the local overrides are stored in separate files, making sure local configuration do not affect changes to the package default, and thus no question is asked during upgrade. This is best design, certainly, but can be rather difficult to do if upstream is not using a cooperative mechanism. In contrast, if upstream has DTRT, this should require no maintainer work. Oh well. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote:
the simple fact that a postinst script fails because a change has been
refused isn't - and for sure it is not a serious or grave bug,
severities often used when a postinst fails.
Opinions?
without knowing more about package x, i would suggest that this is
a bug in the packaging that the postinst script failed if said
program/utility/daemon was not able to function. imho, definitely not
serious or grave, as it affects some, not all and is more
of a misconfiguration issue.
i would suggest that errors from such programs should induce warnings,
but not be fatal to the installation of the package. for example, if
i had customized mysql's my.cnf and in an upgrade an obsoleted option
caused the server not to start, it should not prevent the installation
from completing, though the error message displayed by invoke-rc.d would
certainly be enlightening. and mentioning the potential problem in
{README,NEWS,Changelog}.Debian could be helpful too.
sean
--
signature.asc
Description: Digital signature
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
sean finney [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: the simple fact that a postinst script fails because a change has been refused isn't - and for sure it is not a serious or grave bug, severities often used when a postinst fails. Opinions? without knowing more about package x, i would suggest that this is a bug in the packaging that the postinst script failed if said program/utility/daemon was not able to function. You mean the postinst script should succeed even if the program is not able to work? This doesn't fit with the meaning of Depends, because other packages declare a Depends exactly because they want to use the program, they want it to function. If they cannot rely on it's working after the postinst has completed successfully, this a severe bug IMO. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On Mon, 2005-10-31 at 18:56 +0100, Frank Küster wrote: Because one of the changes in the new version was crucial for the function of the program, the postinst script fails to initialize it, and the whole installation process fails. Would it be possible to modify the program so that it is more robust with respect to this specific configuration setting? What kind of setting is it that causes the program to fail where a previous version appearently worked? It would sound to me like the solution that serves all in the best way. regards, Thijs signature.asc Description: This is a digitally signed message part
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote: You mean the postinst script should succeed even if the program is not able to work? This doesn't fit with the meaning of Depends, because other packages declare a Depends exactly because they want to use the program, they want it to function. If they cannot rely on it's working after the postinst has completed successfully, this a severe bug IMO. What you are describing sounds like a Pre-Depends. That is, package y Depends on package x being installed and properly configured before package y can be installed. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpGCS0aJcltf.pgp Description: PGP signature
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Hi, to make it clear to everybody: The package that brought this up is teTeX, but I think the point is more general Thijs Kinkhorst [EMAIL PROTECTED] wrote: On Mon, 2005-10-31 at 18:56 +0100, Frank Küster wrote: Because one of the changes in the new version was crucial for the function of the program, the postinst script fails to initialize it, and the whole installation process fails. Would it be possible to modify the program so that it is more robust with respect to this specific configuration setting? What kind of setting is it that causes the program to fail where a previous version appearently worked? It would sound to me like the solution that serves all in the best way. It's an upstream change. In fact it has been several upstream changes in several cases; most of the time they were either about renamed files or variables, new directories were essential files are expected, or a change in the TeX engine used for a particular format¹. Of course it would be best to be simply more robust, but it's not always possible. For example, in previous teTeX versions, the directories that were searched for input files had a big, inconsistent, messy mixture of names: TEXMFMAIN and TEXMFLOCAL, but VARTEXMF, and so on. Now upstream has decided to rename them all, so that the names are TEXMFsomething. These variables can be changed by a configuration file, and some of them *must* be set. Now if a user refuses to accept the change that switches from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer work. There's no way around that except patching the upstream sources to either revert the change, or look at both variables. Both would mean to deviate considerably from upstream, without a perspective when this could end, the latter would additionally mean heavy changes to the source code. I know that other packages had similar problems, and sometimes the solution was to simply create a new package name, so that the user had to explicitly install, e.g., apache2. In the case of apache the additional benefit of this solution is that one can choose when to switch, or to continue to use the old one. But for teTeX I don't think that anybody would want to stick to the old. Regards, Frank ¹if you don't understand that, forget it; it does not matter -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Roberto C. Sanchez [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote: You mean the postinst script should succeed even if the program is not able to work? This doesn't fit with the meaning of Depends, because other packages declare a Depends exactly because they want to use the program, they want it to function. If they cannot rely on it's working after the postinst has completed successfully, this a severe bug IMO. What you are describing sounds like a Pre-Depends. That is, package y Depends on package x being installed and properly configured before package y can be installed. No, it's just Depends. Package y depends on package x being installed *and* properly configured before y can be configured or used. If package x is marked as properly configured, but it cannot be used (by package y's postinst, or during normal operation of y) because of the conffile problem, this is a serious bug. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote: You mean the postinst script should succeed even if the program is not able to work? This doesn't fit with the meaning of Depends, because what i meant was that if you're running some utility in the postinst that might fail for some reason, you should consider whether or not the failure of the program should necessitate the failure of the package's installation. there are cases where the failure of a program definitely should fail the installation, but not knowing more about your particular situation (and not knowing as much about the internals of tetex), i can't make a judgement in your situation. all i'm saying is that if this situation occurs, would it be easier to remedy with a half-installed set of packages, or with the new tetex installed and an error message + documentation telling the admin what to do to fix it? sean -- signature.asc Description: Digital signature
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
sean finney [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 07:52:27PM +0100, Frank Küster wrote: You mean the postinst script should succeed even if the program is not able to work? This doesn't fit with the meaning of Depends, because what i meant was that if you're running some utility in the postinst that might fail for some reason, you should consider whether or not the failure of the program should necessitate the failure of the package's installation. It does - that's all this question is about. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Hello assume that an update to a package brings in a changed conffile, and because the local admin had changed the conffile, he is asked, and he refuses to accept the changed version. This brings up an issue that is bothering me as a user since a long time. Whenever I change a config file, I have to take care and examine changes of the config file in its pacakge. Because most times those provide some enhancments (e.g. commented out proposals for new options available), mostly it is a good idea to merge the changes into my own config. Currently I have to do this merge by hand. However it would be much smarter to have an option [M]erge when configuring, allowing to merge the changes into the the local config file [1]. (Of course there should be also something like: preview merge and preview diff merge with current config). I know this is a little bit tricky, because it requires the old versions of the config files to be available, and therefore requires a change in the package system (keeping the old config files in a seperate location e.g. /var/etc.orig/). Now I have two questions: Is such a feature generally desirable? Is there someone willing to give it some thought and implement it (I am currently short in time) or should I file a wishlist bug against dpkg? I think having an option Merge is far better than just to keep the old file. New vital changes would be propagated to the administrators conffiles. Problems would only occur when conflicts appear (detectable), or if the maintainer uses a deprecated option (not detectable, but happens with the current solution too). Best regards Ben [1] I'm thinking of something similar to CVS/SVN merge here -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Benjamin Mesing [EMAIL PROTECTED] wrote: Now I have two questions: Is such a feature generally desirable? Is there someone willing to give it some thought and implement it (I am currently short in time) or should I file a wishlist bug against dpkg? Yes, I think it *is* desirable; and in a sense it is already implemented in ucf with its --three-way option. On the other hand, the existence of ucf is a big bug in dpkg, anyway, and finally both functions - ucf's primary purpose, renaming and moving-to-other-packages of conffiles, and the three-way merge - should be included in dpkg. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On 10/31/05, Benjamin Mesing [EMAIL PROTECTED] wrote: This brings up an issue that is bothering me as a user since a long time. Whenever I change a config file, I have to take care and examine changes of the config file in its pacakge. Because most times those provide some enhancments (e.g. commented out proposals for new options available), mostly it is a good idea to merge the changes into my own config. Currently I have to do this merge by hand. However it would be much smarter to have an option [M]erge when configuring, allowing to merge the changes into the the local config file [1]. (Of course there should be also something like: preview merge and preview diff merge with current config). I know this is a little bit tricky, because it requires the old versions of the config files to be available, and therefore requires a change in the package system (keeping the old config files in a seperate location e.g. /var/etc.orig/). Now I have two questions: Is such a feature generally desirable? Is there someone willing to give it some thought and implement it (I am currently short in time) or should I file a wishlist bug against dpkg? I think it's a good idea. It'd also allow you to easily find all the changes you made compared to the original conf files, which is handy for backups. I think having an option Merge is far better than just to keep the old file. New vital changes would be propagated to the administrators conffiles. Problems would only occur when conflicts appear (detectable), or if the maintainer uses a deprecated option (not detectable, but happens with the current solution too). Best regards Ben [1] I'm thinking of something similar to CVS/SVN merge here -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Benjamin Mesing [EMAIL PROTECTED] writes: Hello assume that an update to a package brings in a changed conffile, and because the local admin had changed the conffile, he is asked, and he refuses to accept the changed version. This brings up an issue that is bothering me as a user since a long time. Whenever I change a config file, I have to take care and examine changes of the config file in its pacakge. Because most times those provide some enhancments (e.g. commented out proposals for new options available), mostly it is a good idea to merge the changes into my own config. Currently I have to do this merge by hand. However it would be much smarter to have an option [M]erge when configuring, allowing to merge the changes into the the local config file [1]. (Of course there should be also something like: preview merge and preview diff merge with current config). I know this is a little bit tricky, because it requires the old versions of the config files to be available, and therefore requires a change in the package system (keeping the old config files in a seperate location e.g. /var/etc.orig/). Now I have two questions: Is such a feature generally desirable? Is there someone willing to give it some thought and implement it (I am currently short in time) or should I file a wishlist bug against dpkg? #32877 #48717 #120152 #189805 #247336 #268154 #290854 #294073 6 years and 271 days old. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: In my opinion this is not a bug (except if the package is crucial for the system to work and be reachable, like ssh) - the local admin simply has to review the changes to conffiles that dpkg requested, and have a look at NEWS.Debian and changelog.Debian. If these files do not contain enough information to fix the system, then this is a bug, right? But the simple fact that a postinst script fails because a change has been refused isn't - and for sure it is not a serious or grave bug, severities often used when a postinst fails. Opinions? There is one big problem with that scenario that I haven't seen mentioned in this thread yet: If I make the dist-upgrade of a machine from sarge to etch and the dist-upgrade fails right in the middle of the installed 3000 packages I will be severly disappointed to say the least if that didn't happen for a very good reason... That's a fact that often gets lost when discussing such problem from developer to developer that install sid on their machines and update about 30 packages at once. So if it is at all possible to avoid failing the postinst (which of course also means to not break other packages installation as you have pointed out) it should be done. If it is at all possible in the case of tetex I can't tell, though. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
