Re: stop the manage with debconf madness
Perhaps it would, if it had not come on the tails of a string of unwarranted insults against other developers (most of whom seem to agree with my ideas on the technical subject under discussion). The closest I got to an insult was accusing Manoj of having a prune up his rear. In comparison I have been called most names under the sun in both public and private responses to my emails. This matches with my assertion that a minority of people get too excited when their precious Debian is perceived to be under attack or not technically pure enough (another issue not directly related to this thread). All I have said to date is that the overwrite question was suggested in the past by another developer as a way of dealing with the problem when it came up before. Some of us implemented the suggestion and it seems no one has had a problem with it until now (I have had no bug reports on this). There are other suggestions now that may accomplish the same thing (though I don't like the XML or UCF stuff as they add dependencies) and when the dust has settled I'm sure I will implement the recommendation put forward. Matt.
Re: stop the manage with debconf madness
On Mon, Apr 21, 2003 at 11:21:59AM +0100, Matt Ryan wrote: Perhaps it would, if it had not come on the tails of a string of unwarranted insults against other developers (most of whom seem to agree with my ideas on the technical subject under discussion). The closest I got to an insult was accusing Manoj of having a prune up his rear. ...and telling Ben Collins to take a Valium after what appeared to be a pretty even-handed message ...calling Joey Hess jumped up and being generally rude in response to a justifiably exasperated message about a long-standing problem, which was accompanied by a standing offer to assist any developer with interfacing with debconf ...and stating that you'll use debconf how [you] please and if that's against the 'pure' view of others [...] then its [sic] just hard luck. The first two being insulting to the developers involved, and the third being insulting to the spirit of cooperation and consensus that the project as a whole depends on. -- - mdz
Re: stop the manage with debconf madness
On Mon, 21 Apr 2003 11:21:59 +0100, Matt Ryan [EMAIL PROTECTED] said: All I have said to date is that the overwrite question was suggested in the past by another developer as a way of dealing with the problem when it came up before. Some of us implemented the suggestion and it seems no one has had a problem with it until now (I have had no bug reports on this). There are other suggestions now that may accomplish the same thing (though I don't like the XML or UCF stuff as they add dependencies) and when the dust has settled I'm sure I will implement the recommendation put forward. There were serious bugs filed on TeTeX about this, so the statement that there were no bugs or complaints is not correct. Why do you need to wait until dust settles to stop violating policy? manoj -- A diplomat is man who always remembers a woman's birthday but never her age. Robert Frost Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On Mon, 21 Apr 2003 11:15:46 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Mon, Apr 21, 2003 at 11:21:59AM +0100, Matt Ryan wrote: Perhaps it would, if it had not come on the tails of a string of unwarranted insults against other developers (most of whom seem to agree with my ideas on the technical subject under discussion). The closest I got to an insult was accusing Manoj of having a prune up his rear. ...and telling Ben Collins to take a Valium after what appeared to be a pretty even-handed message And telling him, repeatedly, that he had his foot in his mouth. ...calling Joey Hess jumped up and being generally rude in response to a justifiably exasperated message about a long-standing problem, which was accompanied by a standing offer to assist any developer with interfacing with debconf ...and stating that you'll use debconf how [you] please and if that's against the 'pure' view of others [...] then its [sic] just hard luck. The first two being insulting to the developers involved, and the third being insulting to the spirit of cooperation and consensus that the project as a whole depends on. manoj -- YOU PICKED KARL MALDEN'S NOSE!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Jumped up developers [Re: stop the manage with debconf madness]
Unfortunately your choice is rather weak and doesn't back up your argument so I feel obliged to continue the thread a bit further (plus its giving my brain some exercise). [Oh yeah, the quotes are from some developer who's name I've promised not to use in my emails] ...and telling Ben Collins to take a Valium after what appeared to be a pretty even-handed message Unless he's a lunatic who has to take valium to keep some control I don't see what's wrong with that. Many people would use a similar analogy to indicate to someone they need to crank it down a notch or two. ...calling Joey Hess jumped up and being generally rude in response to a justifiably exasperated message about a long-standing problem, which was accompanied by a standing offer to assist any developer with interfacing with debconf Nope, I never did such a thing. Read the message properly to see what was said. The message specifically refers to the view of others and state my intention to ignore jumped up developers (note the plural). I did however state I wasn't necessarily going to stick my hand in the fire on the word of soneone else. ...and stating that you'll use debconf how [you] please and if that's against the 'pure' view of others [...] then its [sic] just hard luck. The first two being insulting to the developers involved, and the third being insulting to the spirit of cooperation and consensus that the project as a whole depends on. And the bit that the jumped up developers don't seem to understand is the co-operation and consensus. I constantly see comments on how we should restrict the number of maintainers, how we need to make sure everyone's packages measures up to some indication of worth and importance and how if you have not got stuck in with some technical solution in the dim and distant past then your opinion isn't worth jack. My vision of inclusiveness means that everyone gets a say whether its liked it or not. There are no ranks in Debian, no one gets paid (AFAIK) and so no view is more or less valid than another. I think a small minority of developers can easily get identified as pushing their own agendas if we did an informal poll on this list. Those are the one's I have issue with and will continue to say so. Most likely a strong feeling to respond to this message will promote you to the top of the list 8-) Matt.
Re: Jumped up developers [Re: stop the manage with debconf madness]
On Mon, Apr 21, 2003 at 06:33:49PM +0100, Matt Ryan wrote: [more of the same] Plonk. -- - mdz
Re: Jumped up developers [Re: stop the manage with debconf madness]
* Matt Ryan ([EMAIL PROTECTED]) wrote: There are no ranks in Debian, no one gets paid (AFAIK) and so no view is more or less valid than another. I think a small minority of developers can easily get identified as pushing their own agendas if we did an informal poll on this list. Those are the one's I have issue with and will continue to say so. Most likely a strong feeling to respond to this message will promote you to the top of the list 8-) If you don't let me have the last word then I'm gonna put you on my list Nyeh! Nyeh! The view of experiance and intelligence is much more valid than that of inexperiance and stupidity. If you havn't got an agenda chances are good that you're not doing much useful. Stephen pgplCwblNJtDV.pgp Description: PGP signature
Re: Jumped up developers [Re: stop the manage with debconf madness]
On Mon, Apr 21, 2003 at 06:33:49PM +0100, Matt Ryan wrote: And the bit that the jumped up developers don't seem to understand is the co-operation and consensus. I constantly see comments on how we should restrict the number of maintainers, how we need to make sure everyone's packages measures up to some indication of worth and importance and how if you have not got stuck in with some technical solution in the dim and distant past then your opinion isn't worth jack. My vision of inclusiveness means that everyone gets a say whether its liked it or not. People can say whatever they want. They can say that 2+2=5. That doesn't make it be technically correct. There are no ranks in Debian, no one gets paid (AFAIK) and so no view is more or less valid than another. Absolutely not. For issues involving questions of fact, some views are correct, and views are incorrect. For other issues, we *must* all agree to do things a certain way, or the project loses all coherence. That's what policy is all about. If your view goes against what Policy dictates, you can argue that Policy should be changed, but to say that your view is just as important as any other is not a valid argument which justifies violating Policy. And ultimately, your assertion is fundamentally incorrect because we can ultimately appeal a question to the technical committee, and once they have ruled, then one particular view *is* valid, and another particular *is* invalid. I think a small minority of developers can easily get identified as pushing their own agendas if we did an informal poll on this list. Those are the one's I have issue with and will continue to say so. Most likely a strong feeling to respond to this message will promote you to the top of the list 8-) Ad hominmem. If you think they are pushing their own agenda, then identify it. What I've seen so far on this thread is an honest desire to improve the quality of the Debian distribution. Consistency between packages and avoidance of using debconf to either (a) display silly and inane messages about binutils, or (b) as a way to blow away user managed configuration files are both things which we should strive for towards improving the quality of the overall Debian distribution. As such, those are agendas for the public good, and not what I would call private agendas. - Ted
Re: Jumped up developers [Re: stop the manage with debconf madness]
Matt Ryan [EMAIL PROTECTED] writes: Unfortunately your choice is rather weak and doesn't back up your argument so I feel obliged to continue the thread a bit further (plus its giving my brain some exercise). [Oh yeah, the quotes are from some developer who's name I've promised not to use in my emails] Is that necessary? ...and telling Ben Collins to take a Valium after what appeared to be a pretty even-handed message Unless he's a lunatic who has to take valium to keep some control I don't see what's wrong with that. Many people would use a similar analogy to indicate to someone they need to crank it down a notch or two. It is insulting nonetheless. Certainly there are stronger insults, but that Valium thing was not necessary. Furthermore, you have not engaged in serious discussion about what the issue was. Hans Reiser accused Debian as a whole of plagiarism and asked whether we support some mysterious de-crediting of Stallman and KDE by RedHat, whatever that is supposed to mean. As of yet, he has not even explicitly stated what the exact license violation is, so we started guessing. Most probably he means removal of 24 lines of listing of sponsors, advertising of paid support etc. from the output of mkreiserfs and similar tools. In my opinion this is not compatible with GPLv2 (which is claimed to be the license of reiserfs), and thus the whole Reiser rant qualifies as trolling, no matter whether he is an upstream author or not. Ben Collins actually advised him on the recommended course of action, i.e. filing a bug/contacting the maintainer. There are no ranks in Debian, no one gets paid (AFAIK) and so no view is more or less valid than another. I think a small minority of developers can easily get identified as pushing their own agendas if we did an informal poll on this list. Those are the one's I have issue with and will continue to say so. Most likely a strong feeling to respond to this message will promote you to the top of the list 8-) I do not count myself as member of the cabal or an important member of the project, maintaining only two chess engines. However, the debconf issue has been discussed in the past, and it seems that some informal consensus involved that debconf is not to be used as a registry. There were some good arguments for that point of view, and a point of view is not much worth if it is not backed up by arguments. The points which stick from your emails are the insults, and that may be due to my superficial reading, but it seems that others have the same impression. (Matt Zimmerman did not even mention the point about anal retentives...) So, please calm down and discuss technical merits of debconf usage, not personal motivations of some imagined developer cabal, Lukas
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, 19 Apr 2003 19:33:21 -0400, Matt Zimmerman [EMAIL PROTECTED] said: As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. Hmm. ucf does show the user the changes, and even offers to merge maintainer changes into the current configuration file. What functionality do you think ucf is missing? manoj -- quit When the quit statement is read, the bc processor is terminated, regardless of where the quit state- ment is found. For example, if (0 == 1) quit will cause bc to terminate. (Seen in the manpage for bc. Note the if statement's logic) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On Sat, 19 Apr 2003 20:21:14 +0100, Matt Ryan [EMAIL PROTECTED] said: Secondly, this isnot a witch hunt. What is being done is that a policy violation in older practice is being pointed out. Alternatives are being discussed; a witch hunt would have involved mass RC bug filings. The TEX discussion is definitely in witchunt territory. Maintainers Really? We are discussion a policy violation that causes loss of user changes, and you think this is a witch hunt? And You happen to be a developer. Seems like a flaw in the NM process (on the whole) try to make the best job they can of the packaging of their programs. Anyone can make mistakes. What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Really a flaw in the NM process. Don't we require peopel to acknowledge the importance of policy nowadays? Diversity is what keeps the human race going... Right. The hell with policy, since following policy is mind less conformance. Jesus. manoj -- There appears to be irrefutable evidence that the mere fact of overcrowding induces violence. Harvey Wheeler Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 02:45:32AM -0500, Manoj Srivastava wrote: Hmm. ucf does show the user the changes, and even offers to merge maintainer changes into the current configuration file. What functionality do you think ucf is missing? In my first message, I listed bullet points for goals, most of which ucf meets, and then outlined the problems with this model, and linked to previous threads discussing them in detail. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01320.html -- - mdz
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, 20 Apr 2003 12:22:31 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Sun, Apr 20, 2003 at 02:45:32AM -0500, Manoj Srivastava wrote: Hmm. ucf does show the user the changes, and even offers to merge maintainer changes into the current configuration file. What functionality do you think ucf is missing? In my first message, I listed bullet points for goals, most of which ucf meets, and then outlined the problems with this model, and linked to previous threads discussing them in detail. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01320.html From my reading of that message, about the only thing that is missing is using debconf to ask the questions. Have I missed anything? (I must confess I only skimmed the first few layers of the message tree you pointed to as references; from my memory of those discussions, there was little new, and the consensus seemed to have been reached for post-inst prompting). Using debconf is on the TODO list for ucf, and perhaps a rewrite of the current prototype in C for speed later down the line. manoj -- Smear the road with a runner!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 12:59:27PM -0500, Manoj Srivastava wrote: On Sun, 20 Apr 2003 12:22:31 -0400, Matt Zimmerman [EMAIL PROTECTED] said: In my first message, I listed bullet points for goals, most of which ucf meets, and then outlined the problems with this model, and linked to previous threads discussing them in detail. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01320.html From my reading of that message, about the only thing that is missing is using debconf to ask the questions. Have I missed anything? (I must confess I only skimmed the first few layers of the message tree you pointed to as references; from my memory of those discussions, there was little new, and the consensus seemed to have been reached for post-inst prompting). Yes, debconf would seem to be the only item in that list that ucf does not implement, now that the three-way option is documented in 0.12 (18 Apr). Using debconf is on the TODO list for ucf, and perhaps a rewrite of the current prototype in C for speed later down the line. ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. If such a system is to be used for a large number of packaging, this would mean moving a large number of prompts into postinst, which I think is undesirable. -- - mdz
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the current live configs be overwritten only in the postinstall phase by dpkg or postinst scripts if the rest of the installation went well? - Jarno
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 09:48:48PM +0300, Jarno Elonen wrote: ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the current live configs be overwritten only in the postinstall phase by dpkg or postinst scripts if the rest of the installation went well? Again: see my first message and followups for a specific, concrete example of why this won't work. -- - mdz
Re: stop the manage with debconf madness
What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Really a flaw in the NM process. Don't we require peopel to acknowledge the importance of policy nowadays? Please. I assume we are both adults (I am at least). Therefore we should be able to have a sensible debate without getting too heated about it. Right. The hell with policy, since following policy is mind less conformance. I never suggested to throw out policy (perhaps you should revisit my email). All I said was that this was prior best practice and now we might make a change. Do not burn everyone for trying their best to make things easy for users just because someone has a bee in their bonnet over this issue. Eventually someone (MDZ seems to be starting this again) will come up with a sensible solution (that doesn't predepend on some configuration program bloat) that will deal with this. Then we can all move over to using that and everyone will the happy again. Matt. Note: That's happy until the next time someone gets all fussed up over the wrong location for a configuration file.
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, 20 Apr 2003 21:48:48 +0300, Jarno Elonen [EMAIL PROTECTED] said: ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the current live configs be overwritten only in the postinstall phase by dpkg or postinst scripts if the rest of the installation went well? Well, for configuration files that require the unpacked package to generate, you can't ask during preconfiguration. For files created using non essential packages, you need to wait until postinst, or else those utilities may not be available. Thus, in a number of cases, the ``new'' configuration file is not determinable in the preinst phase. Even for files in the package there is no way for ucf to get at them -- especially given that the files handled by ucf are not conffiles, and thus mingled in the package data. manoj -- Virtue is a relative term. Spock, Friday's Child, stardate 3499.1 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On Sun, Apr 20, 2003 at 09:06:38PM +0100, Matt Ryan wrote: Eventually someone (MDZ seems to be starting this again) will come up with Please avoid using my name in support of your arguments. I rather not be associated with your recent publicity. -- - mdz
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase [...] Again: see my first message and followups for a specific, concrete example of why this won't work. Thanks, I read the thread. So the reason was that configuration file generation is mostly done in postinst scripts? I didn't quite get why it couldn't in practically all cases be done in preinst (or even a completely new installation if required), though. Could you provide some counter-example(s)? I doubt the (pre-)dependencies on tools used for generation would really be a problem - the generation scripts are usually quite simple and can usually use pretty standard tools that don't change much. - Jarno
Re: stop the manage with debconf madness
On Sun, 20 Apr 2003 21:06:38 +0100, Matt Ryan [EMAIL PROTECTED] said: I never suggested to throw out policy (perhaps you should revisit my email). All I said was that this was prior best practice and now we might make a change. Any prior practice that promotes not preserving user changes ad comments (despite all that policy says on that subject) can't possibly be deemed best. Do not burn everyone for trying their best to make things easy for users just because someone has a bee in their bonnet over this issue. Throwing away user changes is doing ones best for them? Since when? And when is doing something suboptimally been excusable by whining but I was doing my best? Making mistakes is not an issue. Everyone makes them. Mindlessly defending practices that go against what we promise our users, despite being told by several other developers, is a level of intransigence that is unacceptable. Eventually someone (MDZ seems to be starting this again) MDZ seems to be (sinsibly) distancing himself from your stance. will come up with a sensible solution (that doesn't predepend on some configuration program bloat) that will deal with this. Then we can all move over to using that and everyone will the happy again. Heh. The solution, when presented to you that does keep the admin in the loop whenever their changes would be blown away, while allowing generation of new configuration files via debconf or other programmatic means, it is bloat, even when under 20KB of code. So, while you are wringing your hands over the hurt sensibilities of practitioners of a practice that discards user changes, do _you_ have any constructive suggestions that can be rapidly prototyped, and put into use soon, and are not, in your considered opinion, bloat? manoj -- You! What PLANET is this! McCoy, The City on the Edge of Forever, stardate 3134.0 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the [...] Well, for configuration files that require the unpacked package to generate, you can't ask during preconfiguration. For files created using non essential packages, you need to wait until postinst, or else those utilities may not be available. I have a feeling that these cases are actually quite rare. At least with a little help, the developers currently facing those few cases would most likely be able to split their packages so that proper pre-depends could be applied. Or am I provably being too optimistic? - Jarno
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, 20 Apr 2003 23:49:50 +0300, Jarno Elonen [EMAIL PROTECTED] said: Thanks, I read the thread. So the reason was that configuration file generation is mostly done in postinst scripts? I didn't quite get why it couldn't in practically all cases be done in preinst (or even a completely new installation if required), though. Could you provide some counter-example(s)? my package contains /usr/bin/floobargle that I use to analize the system to create a configuration file. /usr/bin/floobargle is not available until unpacked. Or, I have a file I can generate, which is in /usr/lib/foo/bar.conf; and this file is large, and changes often, I do not want to embed it inline in my packages preinst file. I doubt the (pre-)dependencies on tools used for generation would really be a problem - the generation scripts are usually quite simple and can usually use pretty standard tools that don't change much. It depends on what I use to generate the file. A few xml files, a little bit of xsl transofrms, and you have a ton of prepends. manoj -- I was recently on a tour of Latin America, and the only regret I have was that I didn't study Latin harder in school so I could converse with those people. Danforth Quayle Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
I demand that Matt Zimmerman may or may not have written... On Sun, Apr 20, 2003 at 09:06:38PM +0100, Matt Ryan wrote: Eventually someone (MDZ seems to be starting this again) will come up with Come up with what? Let's restore some context... a sensible solution (that doesn't predepend on some configuration program bloat) that will deal with this. Please avoid using my name in support of your arguments. I rather not be associated with your recent publicity. Ahem. From here, given that reference to a sensible solution and your proposed handling posting (which looks like it'll become Something Useful), that looks like look, things are heading in the right direction again. Maybe you were too quick to criticise Matt and to distance yourself? -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | This space reserved for future expansion Beware of friends who are false and deceitful.
Re: stop the manage with debconf madness
On Sun, Apr 20, 2003 at 11:22:48PM +0100, Darren Salt wrote: Ahem. From here, given that reference to a sensible solution and your proposed handling posting (which looks like it'll become Something Useful), that looks like look, things are heading in the right direction again. Perhaps it would, if it had not come on the tails of a string of unwarranted insults against other developers (most of whom seem to agree with my ideas on the technical subject under discussion). -- - mdz
Re: stop the manage with debconf madness
From: Manoj Srivastava [EMAIL PROTECTED] Subject: Re: stop the manage with debconf madness Date: Sun, 20 Apr 2003 02:58:10 -0500 (on the whole) try to make the best job they can of the packaging of their programs. Anyone can make mistakes. Yes and you can too, further policy can too. What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Really a flaw in the NM process. Don't we require peopel to acknowledge the importance of policy nowadays? I (and Matt too, I believe) acknowledge the importance of policy so ask to correct it if it it is not enough for the recent situation or something, right? 2003-4-21(Mon) -- Debian Developer Debian JP Developer - much more I18N of Debian Atsuhito Kohda [EMAIL PROTECTED] Department of Math., Tokushima Univ.
Re: stop the manage with debconf madness
On Mon, 21 Apr 2003 09:57:41 +0900 (JST), Atsuhito Kohda [EMAIL PROTECTED] said: From: Manoj Srivastava [EMAIL PROTECTED] Subject: Re: stop the manage with debconf madness Date: Sun, 20 Apr 2003 02:58:10 -0500 (on the whole) try to make the best job they can of the packaging of their programs. Anyone can make mistakes. Yes and you can too, further policy can too. Are you saying the policy directive to preserve user changes is a mistake? What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Really a flaw in the NM process. Don't we require peopel to acknowledge the importance of policy nowadays? I (and Matt too, I believe) acknowledge the importance of policy so ask to correct it if it it is not enough for the recent situation or something, right? Parse error. manoj -- Hi! You have reached 555-0129. None of us are here to answer the phone and the cat doesn't have opposing thumbs, so his messages are illegible. Please leave your name and message after the beep... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
Personally I use the ask-about-overwrite question in debconf because the last time this thread came up the only sensible solution was put forward in the attached email. Now, I'm all for a better solution when it is determined what that is, *but* I'm not for a witch hunt based on what was seen to be previous best practice. Matt. ---BeginMessage--- On Mon, Jan 15, 2001 at 07:40:00PM +1000, Jason Henry Parker wrote: [1] : Actually the file in question was a conffile as well as being edited by debconf, but whatever. Herein lies the problem, as I see it. This is a common policy violation because maintainers often want this functionality, but it clashes with policy, or is not addressed. With old-style use of conffiles, package maintainers simply provided a default conffile, which they could update from time to time, and the USER was responsible for merging in their local changes. This was easy on package maintainers, but hard on users. Some packages cannot supply a reasonable default configuration for all users, and/or would like to make the user's life easier by asking a few questions and generating a configuration file. In the pre-debconf era, this would be done by a packageconfig script, a la exim or magicfilter. Once the config file was generated, it would be left alone forever. The user could reconfigure at any time by running the script. If the config file format changed or some such, the user is responsible for re-running the config script and generating a new config file. In this age of debconf, we now have standard tools for asking the user questions (debconf) and reconfiguring a package (dpkg-reconfigure). In order to use these mechanisms successfully, we need some way to peacefully coexist with the user's manual changes. The key change is that package configuration via these tools is done _by maintainer scripts_, rather than by supplying a default conffile or running a script. Policy specifically forbids the editing of conffiles by maintainer scripts ([1] (must not), [2] (should not)). Now, maintainer scripts using debconf have these options: 1. Hide in a hole, and do things the old way. 2. Only generate an initial configuration, and leave it alone forever thereafter (the configuration file may be a conffile). This is a waste of good infrastructure, and leaves the user feeling cheated. If they want to use that same slick process to create a new configuration, they must remove and reinstall the package. 3. Always overwrite the configuration (the configuration file is NOT a conffile). This may seem appropriate for some packages, for which there is a 1:1 mapping between debconf questions and configuration options, but does not allow the user to preserve their local changes (a bad thing). 4. Try to merge the user's changes into the configuration file (the configuration file is NOT a conffile). This is, in my opinion, almost always a bad idea. Regardless of how few lines such a hack adds to the maintainer scripts, this is not guaranteed to stay simple. If a config file format changes, for example, the maintainer scripts may be required to be able to parse both config file formats and convert between them. This means that the maintainer script's parser must be smarter than the program's own (which can only read one of the formats). Some programs, which use an ancient config file format that is unlikely to ever change, can get away with this, as can programs with very simple name=value shell-alike config files. But I still don't like it. 5. Ask the user whether or not to overwrite their configuration file (the configuration file is NOT a conffile). This is the approach taken by xserver-xfree86. One of the questions asked of the user is (in effect) whether their configuration file should be under their control, or that of the maintainer scripts. If the user opts to have their config file generated for them, manual changes are not preserved and their configuration is freshly generated (in the correct format) based on their answers. If the user opts to write their own config file, the maintainer scripts will leave it alone until the user changes their mind. Option #5 best meets the goals of both users and package maintainers. Its only problem is one of elegance. First, the code and templates to ask the user about each config file and how it should be handled must be duplicated in every package that takes this approach. Second, the packaging system does not know about these configuration files, so the user might have some difficulty determining which package owns it, or how it is managed. This functionality should, I think, be integrated into the packaging system, like the current conffile mechanism. A configuration file should be able to be tagged as either user-managed (behaving exactly as a current conffile) or script-managed. The user should be able to, at any time, switch between
Re: stop the manage with debconf madness
On 18-Apr-03, 10:28 (CDT), Steve Langasek [EMAIL PROTECTED] wrote: If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, If it has a reasonable default, then it should be defaulted. You should not ask questions about it. That's what Debian policy says. If you don't like this, then get policy changed. In particular, if you start asking questions about defaultable configuration values, then you can't make the file a conffile. Debian conffile handling is one of the great things about Debian. Breaking that is A Bad Thing(tm). That's it. Any other use is a clear violation of Debian configuration file policy. In particular, using debconf to modify existing configuration files, whether conffiles or not, is wrong. This claim is not reflected in our actual policy. It's perfectly valid for a maintainer script to make changes to non-conffile config file in response to a user's expression of assent. But only if that assent is obtained each and every time, not by checking what the admin answered 8 months ago on the original install. And the whole thing is better handled using conffiles, where I can diff and merge the changes, when it's convenient for me, rather than hiding them scripts in the middle of a massive upgrade. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: stop the manage with debconf madness
On Sat, 19 Apr 2003 14:07:04 +0100, Matt Ryan [EMAIL PROTECTED] said: Personally I use the ask-about-overwrite question in debconf because the last time this thread came up the only sensible solution was put forward in the attached email. Now, I'm all for a better solution when it is determined what that is, *but* I'm not for a witch hunt based on what was seen to be previous best practice. I'm sorry that all of us can't participate in all the discussions on -devel, and some times the optimal solutions are not reached. But when these solutions were starting to get implemented, I did point out the policy violations, and even filed a few serious bugs about them. I did not have the time or the energy then to do much more. Around the same time, ucf was written to allow one to manage a configuration file, allowing one to generate configuration files on the fly, and still afford the user changes dpkg like protection. In any case, pointing to an old discussion on -devel is not a justification for not preserving user changes. Asking the admin whether one may violate Debian policy ought not to be a license to do as one wishes. Secondly, this isnot a witch hunt. What is being done is that a policy violation in older practice is being pointed out. Alternatives are being discussed; a witch hunt would have involved mass RC bug filings. Debconf did not suddenly give people a reason to not preserve user changes; amd we had already rejected destruction of user changes before (one could have written a mainainter script in 1995 that asked the user once, populated a file in /var/lib/, and forever destroyed user changes, way before debconf). manoj -- Pardon this fortune. Database under reconstruction. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On Sat, Apr 19, 2003 at 11:11:59AM -0500, Steve Greenland wrote: On 18-Apr-03, 10:28 (CDT), Steve Langasek [EMAIL PROTECTED] wrote: If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, If it has a reasonable default, then it should be defaulted. You should not ask questions about it. That's what Debian policy says. If you don't like this, then get policy changed. I agree that turning a config file into a non-conffile *just* so you can ask medium- and low-priority questions is a bad thing. But in the case where there are already questions that need to be asked because there are no reasonable defaults, throwing in some medium- and low-priority questions doesn't hurt anything at all. As for policy, please provide a reference to the section that says maintainers are prohibited from providing greater configurability for users who elect for it. I must be overlooking that section. In particular, if you start asking questions about defaultable configuration values, then you can't make the file a conffile. Debian conffile handling is one of the great things about Debian. Breaking that is A Bad Thing(tm). There are many other reasons why one might need to have a non-conffile config file. The generalization that all debconf prompts for medium-priority questions lead to gratuitous non-conffiles is not helpful. That's it. Any other use is a clear violation of Debian configuration file policy. In particular, using debconf to modify existing configuration files, whether conffiles or not, is wrong. This claim is not reflected in our actual policy. It's perfectly valid for a maintainer script to make changes to non-conffile config file in response to a user's expression of assent. But only if that assent is obtained each and every time, not by checking what the admin answered 8 months ago on the original install. Certainly. And the whole thing is better handled using conffiles, where I can diff and merge the changes, when it's convenient for me, rather than hiding them scripts in the middle of a massive upgrade. In many cases, yes, conffiles are preferable. In the cases where I use debconf, I don't think so. There are still many configuration settings on the system for which there is no sane default, and maintainers should not be discouraged from dealing with these settings in a policy-conformant manner. Indeed, some of my debconf-based config file handling is among the most satisfying code I've written for Debian -- certainly far outstripping upstream's own ability to handle configuration and upgrade issues. Clearly, your experience differs. Are there specific packages you could point out that might be worth looking at in this context, with the hope of helping the maintainers improve them? -- Steve Langasek postmodern programmer pgpHamcprfWyN.pgp Description: PGP signature
Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, Apr 19, 2003 at 02:07:04PM +0100, Matt Ryan wrote: Personally I use the ask-about-overwrite question in debconf because the last time this thread came up the only sensible solution was put forward in the attached email. Now, I'm all for a better solution when it is determined what that is, *but* I'm not for a witch hunt based on what was seen to be previous best practice. There was a more recent discussion about the same idea. A summary of the goals: - Don't try to parse every program's configuration file format - Notice that a non-conffile, autogenerated configuration file has been modified by the user, and don't lose their changes - Provide 3-way merge functionality to incorporate changes without losing modifications in the common case (I hear this is coming for conffiles as well) - Use debconf for prompting - Have all packages do this using a standard toolset, so that all prompting is consistent and well-translated, and certain defaults can be set globally (see the threads below for more discussion about this) I have a clear idea of how I would implement this (and even some code), and I think that these are all achievable. The one thing which would be sacrificed is preconfiguration. Since autogenerated configuration files, unlike conffiles, require non-essential tools in order to build them, this work generally needs to be done in the postinst. This means that we can't know what the new configuration file looks like until the package is being configured. And there's no sense prompting the user ahead of time when they can't see what the changes look like (Do you want to overwrite your modifications with some random garbage I can't show you now? [Yes/No]). Consider xserver-xfree86, whose current debconf setup can use autodetection data from mdetect and read-edid, but this cannot work unless these packages are installed when xserver-xfree86's .config script runs. There is no dependency relationship which can provide this guarantee (and it doesn't sound like a very good idea to have one), so I don't see much of a way around this. However, I think that with suitable defaults and priority settings, the above goals might be worth a sacrifice. Of course, if someone can think up a way to make this work _correctly_ (in terms of user experience) with preconfiguration, that would be fabulous. Prompting about these configuration files in postinst would be no better or worse than the current conffile mechanism, though as Branden pointed out in the previous discussion, the conffile prompting could, in theory, be done at preconfiguration time, since the conffile itself is available in the deb. Generated configuration files, however, are not. What do folk think about this tradeoff? Or is there a way around it? References: http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01572.html http://lists.debian.org/debian-x/2002/debian-x-200210/msg00417.html -- - mdz
Re: stop the manage with debconf madness
Secondly, this isnot a witch hunt. What is being done is that a policy violation in older practice is being pointed out. Alternatives are being discussed; a witch hunt would have involved mass RC bug filings. The TEX discussion is definitely in witchunt territory. Maintainers (on the whole) try to make the best job they can of the packaging of their programs. What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Diversity is what keeps the human race going... Matt.
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Matt Zimmerman There was a more recent discussion about the same idea. A summary of the goals: - Don't try to parse every program's configuration file format - Notice that a non-conffile, autogenerated configuration file has been modified by the user, and don't lose their changes - Provide 3-way merge functionality to incorporate changes without losing modifications in the common case (I hear this is coming for conffiles as well) - Use debconf for prompting - Have all packages do this using a standard toolset, so that all prompting is consistent and well-translated, and certain defaults can be set globally (see the threads below for more discussion about this) Hey, you just described how how ucf can be used. Here's a crash course on how to use it in package fnord's maintainer scripts: fnord.config: db_input fnord/something_that_has_no_good_default_answer db_go fnord.postinst: db_get fnord/something_that_has_no_good_default_answer cat _eof /usr/share/fnord/managed-conffiles/fnord.cf # configuration file for fnord. setting_with_acceptable_default1 = quux setting_with_acceptable_default2 = zoot # this variable hasn't got any good default. variable_with_no_good_default = $RET _eof db_stop ucf /usr/share/fnord/managed-conffiles/fnord.cf /etc/fnord.cf /dev/tty Lo and behold! We've just achieved your goals, using tools already in the archive! If /usr/share/fnord/managed-conffiles/fnord.cf changes, because of a dpkg-reconfigure where the user gives another answer, or a upgrade where the template has been changed by the maintainer (or a combination), and the user has changed /etc/fnord.cf, ucf will pop up a question which closely resembles dpkg's counterpart: Configuration file `/void/home/tore/ucftest/cf' == File on system created by you or by a script. == File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions (...) Local modification will be kept, if the user wants them to be! So there's no reason anyone to supply configuration files with comments such as ## don't edit this file; it belongs to the maintainer scrips!, even if the file is dynamically created. The user doesn't need to know that whether or not not a conffile or a ucf-handled configuration file. But wait! There's more! -- if you supply the --three-way option to ucf in your postinst, the rest of ucf's question looks like this: 3 or T : show a thre way difference between current, older, and new versions of the file M : Do a 3 way merge between current, older, and new versions of the file [Very Experimental] Exactly what you wanted, yes? -- Tore Anderson
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, 2003-04-19 at 15:41, Tore Anderson wrote: cat _eof /usr/share/fnord/managed-conffiles/fnord.cf /var signature.asc Description: This is a digitally signed message part
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, Apr 19, 2003 at 09:41:58PM +0200, Tore Anderson wrote: Hey, you just described how how ucf can be used. I am aware of ucf. I described some things that ucf does, and some things that it does not. Lo and behold! We've just achieved your goals, using tools already in the archive! Not exactly. Exactly what you wanted, yes? Did you read my sample configuration scenario (xserver-xfree86), or the threads that I referenced? They explain in more detail. -- - mdz
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Matt Zimmerman Did you read my sample configuration scenario (xserver-xfree86), or the threads that I referenced? They explain in more detail. I did, and I can't see why ucf can't be done for this purpose, too; As I said, I am suggesting we mimick the conffile mechanism. conffiles are not parsed, but their modification is noticed. My proposed system would not prevent the user from using the menu-driven configuration; it would simple offer them a choice about whether to generate a new configuration using the dialogs, or to preserve their existing configuration. This choice would only be necessary if the file had been modified by hand. As far as I know, ucf is created exactly for this purpose; to mimic dpkg's conffile handing. I assume you want to know if the configuration file is unmodified prior to asking all the debconf questions, and making use of such a command in the ucf package would unfortunately require a pre-dependency. However, such a test would be very simple (basically just checking if the md5sum of the configuration file matches the one recorded in ucf's hashfile), so it could easily be included in the config script. After you've conclusided that you can overwrite the configuration file (possibly by asking the user if the not modified check was negative), you just write the configuration file outside of /etc and call ucf on it. Possibly with UCF_FORCE_CONFNEW if you've asked explicit permission. What am I missing? -- Tore Anderson
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 01:05:18AM +0200, Tore Anderson wrote: As far as I know, ucf is created exactly for this purpose; to mimic dpkg's conffile handing. I assume you want to know if the configuration file is unmodified prior to asking all the debconf questions, and making use of such a command in the ucf package would unfortunately require a pre-dependency. A pre-dependency? We're talking about .config here, not .preinst. As was explained in detail, there is no way to get access to tools in non-essential packages from .config. However, such a test would be very simple (basically just checking if the md5sum of the configuration file matches the one recorded in ucf's hashfile), so it could easily be included in the config script. As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. What am I missing? Generating configuration files using non-Essential tools (including tools contained in the package being configured), the preference to ask all questions at preconfiguration time, and the necessity of displaying proposed changes before asking the user to confirm them. -- - mdz
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, Apr 19, 2003 at 03:14:34PM -0400, Matt Zimmerman wrote: - Provide 3-way merge functionality to incorporate changes without losing modifications in the common case (I hear this is coming for conffiles as well) Great! Actually what I would like (and is similar in ways to the above) is to be able to get two diffs: 1. What did I change in my config file since the last update? 2. What did the package maintainer change since the last update? So if the next version of the package comes with, say a totally different format, currently you will get a huge diff file between your file and the upstream file. This makes it hard to realize but I only changed one setting!, and that transferring to the new configuration might actually be a very easy task, of just copying that one setting across. -- Brian May [EMAIL PROTECTED]
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Matt Zimmerman As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. Of course, this question will be shown in the postinst, if the generated file differs from the previously generated one and the user has modified the one in /etc. I was more thinking along the lines of a question such as: You are upgrading from version 1.23 of package foo. Starting from this version, the configuration file layout has changed drastically, and your old one cannot be used. May I generate a new file based on your previous answers and autodetection tools, overwrite your old configuration file, and save the old one to /etc/foorc.dpkg-old? but I realise that's probably not what you had in mind. * Tore Anderson What am I missing? * Matt Zimmerman Generating configuration files using non-Essential tools (including tools contained in the package being configured), the preference to ask all questions at preconfiguration time, and the necessity of displaying proposed changes before asking the user to confirm them. I see your problem when you insist on asking on asking all questions at the configure stage -- personally, I don't think delaying the actual generating of the configuration file (and asking the question about overwriting the old file) to the postinst stage is *that* bad. All the other questions can be asked at configure phase, though. -- Tore Anderson
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 02:20:00AM +0200, Tore Anderson wrote: * Matt Zimmerman As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. Of course, this question will be shown in the postinst, if the generated file differs from the previously generated one and the user has modified the one in /etc. Yes, and this was the main question that I brought up at the end of my original message: is it worth sacrificing preconfiguration, or is there a better way? So far, there is no clear consensus. I see your problem when you insist on asking on asking all questions at the configure stage -- personally, I don't think delaying the actual generating of the configuration file (and asking the question about overwriting the old file) to the postinst stage is *that* bad. This is the sort of input that I was soliciting. Personally, I think that preconfiguration is very important, since it _greatly_ simplifies initial installation and upgrades (where a large number of questions are asked) and allows the rest of the installation to proceed unattended in the absence of errors. -- - mdz
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
* Tore Anderson I see your problem when you insist on asking on asking all questions at the configure stage -- personally, I don't think delaying the actual generating of the configuration file (and asking the question about overwriting the old file) to the postinst stage is *that* bad. * Matt Zimmerman This is the sort of input that I was soliciting. Personally, I think that preconfiguration is very important, since it _greatly_ simplifies initial installation and upgrades (where a large number of questions are asked) and allows the rest of the installation to proceed unattended in the absence of errors. I fully agree that as many questions as possible should be asked before unpacking the package. And I also agree it would better if the replace the configuration file questions also came at that point of the upgrade, but unfortunately, that isn't the status quo. dpkg asks for permission to overwrite conffiles *after* having unpacked the package in question -- and therefore you cannot dist-upgrade 300 packages, answer all questions, then take lunch and expect it to be finished when you're back. The upgrade will most likely stop after unpacking a package with a new conffile. As you probably know, preconfiguration is handled by apt-extracttemplates, while the conffile mechanism is dpkg's turf. Therefore it would require major changes to apt/dpkg to make those conffile questions appear at the same time as all the other questions asked by apt-extracttemplates. I don't see that change happening in the near future. So, where does that leave us? dpkg's Can I overwrite this conffile? questions are asked some time between the package is unpacked and the postinst is started. ucf's equivalent questions is asked in the postinst, which of course is slightly later in the process, but I highly doubt that a regular user would notice any difference. Hence, as ucf isn't especially worse than dpkg itself when it comes to interrupting upgrades after apt-extracttemplates has preconfigured packages, I don't think ucf's prompt in the postinst is that much of a problem. YMMV. -- Tore Anderson
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 04:11:29AM +0200, Tore Anderson wrote: I fully agree that as many questions as possible should be asked before unpacking the package. And I also agree it would better if the replace the configuration file questions also came at that point of the upgrade, but unfortunately, that isn't the status quo. dpkg asks for permission to overwrite conffiles *after* having unpacked the package in question -- and therefore you cannot dist-upgrade 300 packages, answer all questions, then take lunch and expect it to be finished when you're back. The upgrade will most likely stop after unpacking a package with a new conffile. While this is true, it isn't inherent in the design. conffile prompting could presumably be moved to the preconfiguration stage with relative ease. With dynamically generated configuration files, this is impossible for all but the simple substitution case. -- - mdz
Re: stop the manage with debconf madness
On 16-Apr-03, 18:08 (CDT), Colin Walters [EMAIL PROTECTED] wrote: Debconf is NOT a license to overwrite user's configurations! You've correctly identified the problem. I propose a different solution to this problem, which conforms much more with policy, while still allowing debconf to be used as much as possible. But that's not the solution. Debconf is *NOT* a general purpose configuration tool. Debconf is *ONLY* a standardized way of interacting with the user during package installation, for configuration values that *CANNOT* be reasonably defaulted. That's it. Any other use is a clear violation of Debian configuration file policy. In particular, using debconf to modify existing configuration files, whether conffiles or not, is wrong. I'd allow an exception for dpkg-reconfigure, since this is clear that the admin is deliberately asking for it. Steve, extremely disappointed about how chatty package installation has become. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: stop the manage with debconf madness
On Fri, Apr 18, 2003 at 09:28:07AM -0500, Steve Greenland wrote: On 16-Apr-03, 18:08 (CDT), Colin Walters [EMAIL PROTECTED] wrote: Debconf is NOT a license to overwrite user's configurations! You've correctly identified the problem. I propose a different solution to this problem, which conforms much more with policy, while still allowing debconf to be used as much as possible. But that's not the solution. Debconf is *NOT* a general purpose configuration tool. Debconf is *ONLY* a standardized way of interacting with the user during package installation, for configuration values that *CANNOT* be reasonably defaulted. If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, so unless they're shown to the admin *at his choice*, and the admin actively *chooses* a non-default value, the configuration file won't be changed anyway. Now, if there are questions being asked at priority high or higher that have reasonable defaults, those are bugs. I've had a few of these myself, but no worries -- file and fix, and move on. OTOH, if you're running debconf with a priority preference of medium or lower... RTFM. That's it. Any other use is a clear violation of Debian configuration file policy. In particular, using debconf to modify existing configuration files, whether conffiles or not, is wrong. This claim is not reflected in our actual policy. It's perfectly valid for a maintainer script to make changes to non-conffile config file in response to a user's expression of assent. -- Steve Langasek postmodern programmer pgp8OcZLMODzY.pgp Description: PGP signature
Re: stop the manage with debconf madness
On Fri, 2003-04-18 at 10:28, Steve Greenland wrote: I propose a different solution to this problem, which conforms much more with policy, while still allowing debconf to be used as much as possible. But that's not the solution. Yep, I agree completely. So let's talk about solutions. One might be to create a third class of configuration files; let's call them managed configuration files. Now, managed configfiles can either be conffiles (i.e. included in the package) or configuration files. The key difference is that the admin has full, standardized control over how packages can overwrite these files. For example, we'd have files /etc/conffiles/managed and /etc/conffiles/unmanaged. The /etc/conffiles/managed file would itself be a conffile that would list which configuration files a package can freely overwrite. If the configuration file is a conffile, then dpkg will never prompt even if the file is locally modified; it will just replace it. If it's a configuration file, then the package is free to overwrite any changes in its postinst. I know for sure on my system I'd put all the X keymaps and TeX stuff in here. (Hm, we should probably support globs in this file). Likewise, /etc/conffiles/unmanaged is a list of files that should explicitly never be overwritten by packages. Oh, and we'll want a file like /etc/conffiles/default, which says how to handle config files not in either list above. Obviously, I think Debian should default to config files being unmanaged. But if we end up implementing something like this, I might consider making the default to be managed for Debian Desktop. Or at least have a prompt about it. We'd need a few new tools in (say) dpkg for packages to use to determine whether or not a file is managed and stuff, but that's all mostly detail. Now, we can handle the two cases I posted; Hardcore Unix guy will install Debian, and can rest secure in the knowledge that his manual edits to anything in /etc/ will be preserved. Semi-experienced Newbie has a choice. He can explicitly make stuff managed if he wants. So, opinions? Yeah, it's kind of gross. But the way things are now is far worse.
Re: stop the manage with debconf madness
On Fri, 18 Apr 2003 10:28:57 -0500, Steve Langasek [EMAIL PROTECTED] said: If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, so unless they're shown to the admin *at his choice*, and the admin actively *chooses* a non-default value, the configuration file won't be changed anyway. OK, this is what bugs me. If I have a choice -- if I may chose to be prompted every time, and if I have the choice, every time, to look at the changes, and _then_ decide ot keep the old or move to the new, I have no problem. It is an added bonus if I could have upstream changes merged into my local configuration file when I so desire (use the diff between the upstream maintainer files and patch it into my local file), but that is gravy. What I do not like is being as ked to make a decision about all future upgrades *NO*, when I have no idea what the changes are going to look like. If you give users a choice replace configuration files in the future: 'ask or 'always (pathologically, even 'never), I would be happy. Assuming it is 'always is wrong. Giving user a choice of 'always, or You are on your own, buddy is also wrong. manoj -- Flee at once, all is discovered. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On 18 Apr 2003 11:55:09 -0400, Colin Walters [EMAIL PROTECTED] said: So, opinions? Yeah, it's kind of gross. But the way things are now is far worse. As long as /etc/conffiles/managed, /etc/conffiles/unmanaged, and /etc/conffiles/default are never themselves unmanaged, this would work. And the factory default for /etc/conffiles/default should be managed; and the other two files should be empty. If we standardize on a easy to interpret format for these files, I'll add the logic to ucf to handle these directives. (how about a configuration file path per line for /etc/conffiles/managed and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a single word, which is managed by default; anything other than unmanaged is interpreted as managed?). manoj -- ...computer hardware progress is so fast. No other technology since civilization began has seen six orders of magnitude in performance-price gain in 30 years. Fred Brooks, Jr. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
Colin Walters writes: One might be to create a third class of configuration files; let's call them managed configuration files. Is the choice to be up to the maintainer? If so, I'm afraid that over time almost all configfiles would become managed, as that would be the easy way for maintainers. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: stop the manage with debconf madness
On Fri, 18 Apr 2003 14:04:25 -0500, John Hasler [EMAIL PROTECTED] said: Colin Walters writes: One might be to create a third class of configuration files; let's call them managed configuration files. Is the choice to be up to the maintainer? If so, I'm afraid that over time almost all configfiles would become managed, as that would be the easy way for maintainers. From what I understand, the choice is _not_ the maintainers, since it is encapsulated in /etc/conffile/managed, /etc/conffile/unmanaged, and /etc/conffile/default; all of which are themselves conffiles which are under local admin control. I am happy with the local admin deciding which ones are managed; or not, and where it is OK to blow away local changes; packages making this decision on their own ought to be considered in violation of policy. manoj -- Don't hit a man when he's down -- kick him; it's easier. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On Fri, 2003-04-18 at 15:04, John Hasler wrote: Colin Walters writes: One might be to create a third class of configuration files; let's call them managed configuration files. Is the choice to be up to the maintainer? If so, I'm afraid that over time almost all configfiles would become managed, as that would be the easy way for maintainers. No, in my proposal, it's a local system decision. Package maintainers will have to be aware of managed config files, but they don't control which are and which aren't managed.
Re: stop the manage with debconf madness
On Fri, 2003-04-18 at 13:54, Manoj Srivastava wrote: On 18 Apr 2003 11:55:09 -0400, Colin Walters [EMAIL PROTECTED] said: So, opinions? Yeah, it's kind of gross. But the way things are now is far worse. As long as /etc/conffiles/managed, /etc/conffiles/unmanaged, and /etc/conffiles/default are never themselves unmanaged, this would work. And the factory default for /etc/conffiles/default should be managed; and the other two files should be empty. I agree. If we standardize on a easy to interpret format for these files, I'll add the logic to ucf to handle these directives. (how about a configuration file path per line for /etc/conffiles/managed and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a single word, which is managed by default; anything other than unmanaged is interpreted as managed?). Yep, that's exactly the way I was thinking of it. Cool, I'm glad we're on the same wavelength here. Having it in ucf will be a good first step. In fact, ucf might be the logical place to keep this. By the way, David B Harris has expressed interest in private mail to me in tackling this problem too, hopefully he'll speak up here with his ideas.
Re: stop the manage with debconf madness
Would it already be time for a long term solution that no doubt has been discussed sometimes in the past: looking at configuration files in /etc and ~/.*, most of them are actually very simple. Instead of treating them as flat files with arbitrary content and *generating* the managed ones from debconf DB, you could pretty easily *manipulate* them in a more structured and fine grained way by parsing and unparsing them according to developer/maintainer specified metaconfiguration files. In addition to making merging of version specific changes easier, it also allows different configuration interfaces like Debconf now does but during package use, not just installation. In fact, I have previously experimented with such stuff on proprietary software at my work and our experiences there where quite encouraging: handling of blocks and order of configuration elements weren't as difficult as we though they would be, powerful metaconfiguration files could quite easily be created even with error-reducing GUI tools and while perfect solution apparently doesn't exist, comment preserving proved to be possible in practice. It seems there is already at least one current project for developing a tool like this: http://config4gnu.sourceforge.net/ Comments? - Jarno
Re: stop the manage with debconf madness
On Fri Apr 18, 12:54pm -0500, Manoj Srivastava wrote: On 18 Apr 2003 11:55:09 -0400, Colin Walters [EMAIL PROTECTED] said: So, opinions? Yeah, it's kind of gross. But the way things are now is far worse. As long as /etc/conffiles/managed, /etc/conffiles/unmanaged, and /etc/conffiles/default are never themselves unmanaged, this would work. And the factory default for /etc/conffiles/default should be managed; and the other two files should be empty. If we standardize on a easy to interpret format for these files, I'll add the logic to ucf to handle these directives. (how about a configuration file path per line for /etc/conffiles/managed and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a single word, which is managed by default; anything other than unmanaged is interpreted as managed?). Something else worth thinking about, which I was gonna throw in my example package for all this stuff, is config-file-change priority. ie: It would be nice to differentiate between the entire config format has changed, I will break completely if the old one is used, some parameter options have changed; the old ones will still work - for now, I just changed some defaults, keep what they have now, and I fixed a typo in one of the documentation comments. We could then respect things like DEBCONF_PRIORITY, and not bother the user if all we've changed is the spelling of a descriptive (ie: not example) word in a comment. Pet peeve of mine in dpkg conffile handling :) pgp9z3wRbXkEU.pgp Description: PGP signature
Re: stop the manage with debconf madness
On Fri, Apr 18, 2003 at 05:06:15PM -0400, Colin Walters wrote: On Fri, 2003-04-18 at 13:54, Manoj Srivastava wrote: If we standardize on a easy to interpret format for these files, I'll add the logic to ucf to handle these directives. (how about a configuration file path per line for /etc/conffiles/managed and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a single word, which is managed by default; anything other than unmanaged is interpreted as managed?). Yep, that's exactly the way I was thinking of it. Cool, I'm glad we're on the same wavelength here. Having it in ucf will be a good first step. In fact, ucf might be the logical place to keep this. Let's please try to keep this kind of complication to an absolute minimum, though. Packages should be encouraged to use as simple mechanisms as possible for their configuration files, I feel: where possible, dpkg-handled conffiles should be quite adequate for a large number of cases. I find that the minimalist approach of using as simple configuration file technology as I can in my packages means that I don't try to over-extend them to deal with things which are really better documented well and left up to the admin. IMHO, this is a win. -- Colin Watson [EMAIL PROTECTED]
Re: stop the manage with debconf madness
On Fri, Apr 18, 2003 at 10:28:57AM -0500, Steve Langasek wrote: If the package maintainers are correctly using the debconf priorities, and the admin has chosen a debconf priority that accurately reflects their preferences, why do you care? By definition, any prompts at priority medium or lower have reasonable defaults, so unless they're shown to the admin *at his choice*, and the admin actively *chooses* a non-default value, the configuration file won't be changed anyway. One major problem is that I can't trust you arseholes (you know who you are) to set sensible priorities and defaults. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpmhLO41HmQT.pgp Description: PGP signature
Re: stop the manage with debconf madness
On Thu, 2003-04-17 at 01:08, Colin Walters wrote: I just installed laptop-net, becuase it looked similar to something I'd like to work on. You might want to look at ifupdown-roaming too http://panopticon.csustan.edu/thood/ifupdown-roaming.html -- Thomas Hood [EMAIL PROTECTED]
