Re: Debconf or not debconf : Conclusion
On Sat, Jul 05, 2003 at 02:28:33PM -0500, Steve Langasek wrote: Yet another reasons for wanting to decouple installation and configuration is if some hardware company (such as VA^H^H Emperor Linux) wishes to ship Debian pre-installed on the system. In that case, installation happens at the factory, and not when the user receives it in his/her hot little hands. Given the number of config questions today that have to do with available hardware, I have a hard time believing that a strict split between installation and configuration tasks really addresses the needs of such vendors. It also seems that all of the above are achievable within the framework debconf currently provides You've just contradicted yourself. If it's possible to achieve all of the above within the framework debconf currently provides, then a strict split between installation (preinst, unpack and postinst) and configuratin (config and templates) really addresses the needs of such vendors. If, on the other hand, it doesn't, then it's not. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpF56X8iIXPj.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Sun, Jul 06, 2003 at 03:24:57PM +1000, Anthony Towns wrote: On Sat, Jul 05, 2003 at 02:28:33PM -0500, Steve Langasek wrote: Yet another reasons for wanting to decouple installation and configuration is if some hardware company (such as VA^H^H Emperor Linux) wishes to ship Debian pre-installed on the system. In that case, installation happens at the factory, and not when the user receives it in his/her hot little hands. Given the number of config questions today that have to do with available hardware, I have a hard time believing that a strict split between installation and configuration tasks really addresses the needs of such vendors. It also seems that all of the above are achievable within the framework debconf currently provides You've just contradicted yourself. If it's possible to achieve all of the above within the framework debconf currently provides, then a strict split between installation (preinst, unpack and postinst) and configuratin (config and templates) really addresses the needs of such vendors. If, on the other hand, it doesn't, then it's not. Sorry, all of the above was meant to refer to the three different modes of invoking the dpkg-configure command. I believe it's possible to provide such a split today using debconf, but I don't believe this split addresses the needs of vendors trying to provide pre-installed systems. -- Steve Langasek postmodern programmer pgp6ByR9Pyttt.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 02:36:24PM -0500, Steve Langasek wrote: [...] This upstream change makes no sense from a usability standpoint; this new stunnel package would be pretty useless to me, and I wouldn't want to have it automatically installed on my systems if I were using the previous, working version. By the time a debconf note is sent, it's too late. the new version of stunnel is much better than the old one. i got bitten by the upgrade to 4.0-4 (when the init.d script didn't start stunnel unless ENABLED=1 in /etc/default/stunnel). big deal. i noticed it quickly enough and it took me less than a minute to scan the docs and discover that i should edit /etc/default/stunnel. the worst that happened was that my uucp-over-tcp clients weren't able to connect for a while. IMO, anyone who does an upgrade without bothering to check that important services are still running correctly afterwards is just plain sloppy and deserves whatever their negligence causes. the same applies to anyone who doesn't test upgrades of critical services on another, unimportant machine first...and for really important packages, it's a good idea to make sure you have a backup copy of the old version of the package before upgrading (dpkg-repack is useful here if it has been cleaned out of your local /var/cache/apt/archives)if the new version proves to be broken, revert to the old version. debian packages aren't a substitute for a competent and careful system admin, they're just a tool to make the sysadmin's job easier. craig
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote: If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. how about a configuration option so that debconf notes get sent to an email address rather than to the screen? craig
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). I don't see how this would be much of an improvement. While I agree that packages for which intelligent defaults are possible should simply ship with those defaults set, there are enough packages that don't have sensible defaults to make debconf a good idea. If dpkg-configure is called separately, how does the admin know when there are packages for which it should be called? And if the admin is automatically notified of this, why is this better than simply calling dpkg-configure then and there? Although debconf notes are frequently abused, I haven't given up hope that current problems with other uses of debconf will sort themselves out as the techniques and rules become more familiar to maintainers. -- Steve Langasek postmodern programmer pgpYREqSrTXRn.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 11:06:36PM -0500, Steve Langasek wrote: On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). I don't see how this would be much of an improvement. It means that you don't have to sit through the unpacking and postinst phases, which can be quite tedious. If dpkg-configure is called separately, how does the admin know when there are packages for which it should be called? And if the admin is automatically notified of this, why is this better than simply calling dpkg-configure then and there? Three possibilities: dpkg-configure *.deb; dpkg -i *.deb for a in *.deb; do dpkg -i $a; dpkg-configure $a; done dpkg -i *.deb; dpkg-configure --pending --all The point of decoupling installation and configuration is to let the admin choose which of these scenarios happen, instead of the distribution or the maintainer. The first is appropriate if you're doing installs of many systems (work out how you want it to look, then slam it onto all of them automatically), the second if you're doing an upgrade from aptitude, and the third if you've blatted a standard install from a magazine cover-CD and need to do some final configuration. The original theory was for debconf to make these choices possible (since it was vastly difficult to do it in the days of echo and read blah). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpwF8lSkDjI0.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Sat, Jul 05, 2003 at 05:05:01PM +1000, Anthony Towns wrote: The point of decoupling installation and configuration is to let the admin choose which of these scenarios happen, instead of the distribution or the maintainer. The first is appropriate if you're doing installs of many systems (work out how you want it to look, then slam it onto all of them automatically), the second if you're doing an upgrade from aptitude, and the third if you've blatted a standard install from a magazine cover-CD and need to do some final configuration. Yet another reasons for wanting to decouple installation and configuration is if some hardware company (such as VA^H^H Emperor Linux) wishes to ship Debian pre-installed on the system. In that case, installation happens at the factory, and not when the user receives it in his/her hot little hands. - Ted
Re: Debconf or not debconf : Conclusion
On Sat, Jul 05, 2003 at 08:46:00AM -0400, Theodore Ts'o wrote: On Sat, Jul 05, 2003 at 05:05:01PM +1000, Anthony Towns wrote: The point of decoupling installation and configuration is to let the admin choose which of these scenarios happen, instead of the distribution or the maintainer. The first is appropriate if you're doing installs of many systems (work out how you want it to look, then slam it onto all of them automatically), the second if you're doing an upgrade from aptitude, and the third if you've blatted a standard install from a magazine cover-CD and need to do some final configuration. Yet another reasons for wanting to decouple installation and configuration is if some hardware company (such as VA^H^H Emperor Linux) wishes to ship Debian pre-installed on the system. In that case, installation happens at the factory, and not when the user receives it in his/her hot little hands. Given the number of config questions today that have to do with available hardware, I have a hard time believing that a strict split between installation and configuration tasks really addresses the needs of such vendors. It also seems that all of the above are achievable within the framework debconf currently provides -- or is this about how the default user interface to debconf should be arranged? -- Steve Langasek postmodern programmer pgpHkTeInZQsw.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 04:21:45PM +0200, Julien LEMOINE wrote: I will upload a stunnel4 package and a stunnel with Epoch tomorrow. Excellent decision. :) Thank you. -- G. Branden Robinson| The key to being a Southern Debian GNU/Linux | Baptist: It ain't a sin if you [EMAIL PROTECTED] | don't get caught. http://people.debian.org/~branden/ | -- Anthony Davidson pgpBLRv5BOJyu.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 02:18:10AM +0200, Julien LEMOINE wrote: On Friday 04 July 2003 01:52, Andrew Suffield wrote: What do you propose ? Do you think Debian must keep old version of stunnel (3.x) for compatibility Given how it sounds like upstream are completely incompetent and have decided to gratuitously break compatibility, that sounds like a good idea. and do not include new version ? Why wouldn't you include the new version as well? Yes, keep the two versions of stunnel is probably the right way to handle this problem. Now the problem is that stunnel is uploaded in version 4 on stunnel package. What is the correct way to reintroduce stunnel for compatibility reasons ? uploading a new stunnel3 package will not resolve the problem. Epoch it and upload stunnel4 as a new package. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpWoPzFgPr3C.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote: If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. After seeing multiple attempts to use social pressure to encourage to stop the flood of debconf misusage, it's at times like this that I sometimes think Eric Troan really got this part of rpm's design right (some 7 or 8 years ago) when he completely forbade any I/O between the install scripts and the user at install time. As he put it, (paraphrased since I don't remember his exact wording) if even a small percentage of packagers indulge their desire to put up dialog boxes, the system will become extremely annoying. How prophetic he was --- or rather, how well he understood human nature. Everybody believes that *their* package has something ***so*** important to say that they have to tell the whole world about it. And perhaps I'm being too pessimistic, but trying to fix this by social pressure is like trying to shame American soccer mom's into not driving gasoline-gulping SUV's. It's never going to work. If you want to fix the problem, you have the right idea by thinking that you should perhaps simply disable all notes. That's the only solution that will stop the flood of warning messages and noices. (And perhaps by removing this crutch, packagers will be more encouraged not to grauitiously break things as the result of package upgrades, even if upstream does something stupid.) On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). - Ted
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). - Ted Hear, hear. There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script.
Re: Debconf or not debconf : Conclusion
Marc Singer wrote: There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script. Take a look at invoke-rc.d and its policy program. -- see shy jo pgpADXOdaNxUV.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). Debconf is flexable enough so you can do that already (assuming all packages use debconf). - comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf - set in /etc/debconf.conf: Frontend: noninteractive Admin-Email: - dpkg-configure is the following script: #!/bin/sh -e dpkg-reconfigure --unseen-only --default-priority -freadline $@ -- see shy jo pgpHjE1t7saSk.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:11:48AM -0400, Joey Hess wrote: Theodore Ts'o wrote: On a separate but related topic, I think a much better approach would be to handle configuration as a step entirely separate from the install phase. Let the install be entirely quiet, and let packages have intelligent defaults. If the package absolutely must be configured before it can be used, then let it be non-functional until someone actually calls dpkg-configure (which would be just like dpkg-reconfigure except that's the only time the questions would be asked). Debconf is flexable enough so you can do that already (assuming all packages use debconf). - comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf - set in /etc/debconf.conf: Frontend: noninteractive Admin-Email: - dpkg-configure is the following script: #!/bin/sh -e dpkg-reconfigure --unseen-only --default-priority -freadline $@ My reading of Ted's comment is that this ought to be the *default* policy. I won't go so far as to say that RH made a better choice, but I don't really see the benefit of the all of the warning messages when once displayed they are nowhere to be found. Perhaps, you'll have a command for recovering these messages, but that doesn't change the fact that they are just not really necessary at install time.
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: sometimes think Eric Troan really got this part of rpm's design right (some 7 or 8 years ago) when he completely forbade any I/O between the install scripts and the user at install time. [...] (And perhaps by removing this crutch, packagers will be more encouraged not to grauitiously break things as the result of package upgrades, even if upstream does something stupid.) Unfortunately, this does not happen in the install-time-note-free Red Hat world. I see RH package upgrades break^Wchange things which are not obviously documented and would benefit from a note (or, a la debconf, an email) just mentioning what has occurred. I much prefer the opportunity to warn the admin at install time. Dave
Re: Debconf or not debconf : Conclusion
On Friday 04 July 2003 05:59, Andrew Suffield wrote: Yes, keep the two versions of stunnel is probably the right way to handle this problem. Now the problem is that stunnel is uploaded in version 4 on stunnel package. What is the correct way to reintroduce stunnel for compatibility reasons ? uploading a new stunnel3 package will not resolve the problem. Epoch it and upload stunnel4 as a new package. Thanks, I will upload a stunnel4 package and a stunnel with Epoch tomorrow. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 12:19:16PM -0500, Gunnar Wolf wrote: Keep stunnel as a stub package depending on either stunnel3 or stunnel4, change the description of stunnel3 explaining the situation and urging users to upgrade if possible. Yeah, he could use a debconf note for this for example. scnr, Michael
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 08:53:57PM -0400, Joe Drew wrote: Joey Hess has mentioned, and I agree (see 199722), that debconf notes should really be named (and should always be interpreted as) warnings. Huh. I thought it was supposed to be even stricter than that; errors only. E.g.: Template: xserver-xfree86/config/device/bus_id_error Type: note _Description: Please enter a bus identifier in the proper format. The BusID should be a string in the following format: . bustype:bus:device:function . Where bustype is PCI for PCI and AGP video cards, and each of bus, device, and function is a decimal (not hexadecimal) value. For example, PCI:0:16:0 is valid input (without the double-quotes). I'm trying to get my debconf notes down to just input validation errors. -- G. Branden Robinson| The key to being a Southern Debian GNU/Linux | Baptist: It ain't a sin if you [EMAIL PROTECTED] | don't get caught. http://people.debian.org/~branden/ | -- Anthony Davidson pgpQCEifDZowM.pgp Description: PGP signature
Re: Debconf or not debconf
Joe Drew [EMAIL PROTECTED] wrote:
On Wed, 2003-07-02 at 17:23, Herbert Xu wrote:
I'd prefer no interaction at all during installation. I'm perfectly
able to read documenation thank you very much.
Happily, the noninteractive debconf frontend exists.
And getting hundreds of emails after a mass upgrade? No thanks.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 01:24:54AM +0100, Andrew Suffield wrote: Somehow, you managed to miss the point entirely in your first line, *even though* you restated it later. I don't miss the point at all. You have assumed that it is ok to break the user system and warn people about it. It is not. Do not break the user system. Then no warnings are necessary. Yes, that's what we should be aiming for. Sadly things like upstream changes may make this unreasonably difficult - for example, configuration formats may change substantially in a way that is not ameinable to automated translation or a bug fix may require incompatible changes. If we're left in this unfortunate suituation where we're going to break the user system then we ought to warn them about it. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpshkdnrPR29.pgp Description: PGP signature
Re: Debconf or not debconf
On Thursday, July 3, 2003, at 02:05 AM, Branden Robinson wrote: On Wed, Jul 02, 2003 at 08:53:57PM -0400, Joe Drew wrote: Joey Hess has mentioned, and I agree (see 199722), that debconf notes should really be named (and should always be interpreted as) warnings. Huh. I thought it was supposed to be even stricter than that; errors only. E.g.: [...] input validation errors. IMO, when a debconf warning is shown, the administrator should need to do something. Regardless of whether that something is dumping and re-loading databases, reconfiguring a radically changed package, or re-entering the PCI BusID in a valid format, the warning (or error) informs the administrator that action is required on their part. Anything else should be placed in NEWS.Debian.
Re: Debconf or not debconf
Julien LEMOINE [EMAIL PROTECTED] wrote: On Tuesday 01 July 2003 22:51, Andreas Metzler wrote: Julien LEMOINE [EMAIL PROTECTED] wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Is this just the usual default file for modifying the init-script's behaviour, i.e. will the package just continue to work as it did if the user does not know about it? Not exactly, there is a variable ENABLED which is set to 0 at installation. So the service will not start while variable is not set to 1. I see. I cannot do much more than AOL!! other posters in this thread: Steve Langasek | If so, I would recommend looking for a way to provide a more | graceful upgrade -- this is worth much more than a note telling | users that you've just broken their systems... *If* this is not possible, because it would require you to maintain a big patch differing from upstream and you can't change their minds with [EMAIL PROTECTED] *then* a debconf note with priority high is needed. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Debconf or not debconf
On Wed, 02 Jul 2003 19:52:10 +1000, Herbert Xu [EMAIL PROTECTED] wrote: I for one am sick and tired of useless Debconf messages popping up during installation or being sent to me via email when I'm upgrading hundreds of machines automatically. Just go ahead and pre-seed your debconf database appropriately before upgrading. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Debconf or not debconf
On Thu, Jul 03, 2003 at 12:27:24PM +1000, Herbert Xu wrote: Joe Drew [EMAIL PROTECTED] wrote: On Wed, 2003-07-02 at 17:23, Herbert Xu wrote: I'd prefer no interaction at all during installation. I'm perfectly able to read documenation thank you very much. Happily, the noninteractive debconf frontend exists. And getting hundreds of emails after a mass upgrade? No thanks. man 5 procmailrc Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Debconf or not debconf
On Wed, 02 Jul 2003 22:25:26 +0200 Thomas Viehmann [EMAIL PROTECTED] wrote: Jim Penny wrote: Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. What is difficult to test in ssl connections fail? I routinely test mine with telnet-ssl or python scripts (though I remember something about python and IMAP SSL not too long ago)... Well, you have to have a place to launch the scripts from. It the tunnel is at the edge, and listening only to the outward-facing interface, or it is listening only to localhost, and you don't want to have the testing tools on your firewall, or ... Also, the silentness would IMHO be better fixed by adding a big fat NOT to the init script (although anything more than a NOT will be controversial as well...). Reminds me of something I should fix for my packages... This is a completely different complaint, more of an aside that should never have been raised here. It has nothing to do with the change in format of configuration information, debconf-ing or not debconf-ing. It has to do with the experience of making repeated changes to the configuration file, while feeling under some time pressure, running/etc/init.d/stunnel restart, seeing no output, and thinking silence is golden. You know, the usual Unix tradition. Jim Penny
Re: Debconf or not debconf
#include hallo.h * Herbert Xu [Thu, Jul 03 2003, 12:27:24PM]: I'd prefer no interaction at all during installation. I'm perfectly able to read documenation thank you very much. Happily, the noninteractive debconf frontend exists. And getting hundreds of emails after a mass upgrade? No thanks. We need a mail collector in debconf to send them all in one digest mail. MfG, Eduard. -- claim morgen! weasel was ist morgen? claim aehm, mittwoch!
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. [...] [1] 4. Our Priorities are Our Users and Free Software As a user: You are doing me a disservice. That's one more useless debconf warning, especially, since an automatic update is easy to implement. - Sebastian
Re: Debconf or not debconf
Marc Haber wrote: On Wed, 02 Jul 2003 19:52:10 +1000, Herbert Xu [EMAIL PROTECTED] wrote: I for one am sick and tired of useless Debconf messages popping up during installation or being sent to me via email when I'm upgrading hundreds of machines automatically. Just go ahead and pre-seed your debconf database appropriately before upgrading. Funnily, Russel Coker explained something about this while explaining why he turned away from Micro$oft in the Interview mentioned on debian-planet today... Excessive usage of debconf notices is a bug which should be avoided/fixed, not worked around. Cheers T. pgpvFTqoLkhJL.pgp Description: PGP signature
Re: Debconf or not debconf
Herbert Xu wrote: And getting hundreds of emails after a mass upgrade? No thanks. Admin-Email The email address Debconf should send mail to if it needs to make sure that the admin has seen an important note. Defaults to root, but can be set to any valid email address to send the mail there. If you prefer to never have debconf send you mail, specify a blank address. This can be overridden on the fly with the DEB- CONF_ADMIN_EMAIL environment variable. -- see shy jo pgphlp3EjL0gH.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Hi. Julien LEMOINE wrote: First of all, I present my excuses for having started a new debate about debconf in debian-devel. But then, the last one didn't favor your opinion. Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. Yes. But you still have the options of: - Publically asking if someone else has time and skill to do it. - Putting off the update and/or packaging the interface incompatible stunnel under a new name. Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. There is a difference between the social contract and the DFSG. As a user of stunnel: Your warning will not help me as it does not keep stunnel from breaking. *Not* installing a totally incompatible program where the stunnel I wanted when I said apt-get install stunnel would. Cheers T. pgpSSwZtIe7kk.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Hi Sebastian! You wrote: On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. [...] [1] 4. Our Priorities are Our Users and Free Software As a user: You are doing me a disservice. That's one more useless debconf warning, especially, since an automatic update is easy to implement. Indeed. Please don't display those annoying messages. -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Re: Debconf or not debconf
Jim Penny dijo [Wed, Jul 02, 2003 at 06:34:53PM -0400]: My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. While it is indeed preferable to not break things, there are times when avoiding breakage is quite difficult. This appears, to me, to be one of those times. Many times this cases are handled by creating a transitional package: Keep stunnel as a stub package depending on either stunnel3 or stunnel4, change the description of stunnel3 explaining the situation and urging users to upgrade if possible. Even more, stunnel3 and stunnel4 can coexist - and some users will find it very valuable to have both the newest stunnel features and the ease of keeping their old configurations, or not having to be root to start a temporary or permanent new tunnel. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Debconf or not debconf : Conclusion
On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: First of all, I present my excuses for having started a new debate about debconf in debian-devel. Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. It is not your responsibility to fix all of upstream's bugs, but it *is* your responsibility to protect Debian users from upstream breakage as much as possible. This upstream change makes no sense from a usability standpoint; this new stunnel package would be pretty useless to me, and I wouldn't want to have it automatically installed on my systems if I were using the previous, working version. By the time a debconf note is sent, it's too late. -- Steve Langasek postmodern programmer pgpv8WlinHRRc.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
Julien LEMOINE wrote: Finally, since there is not really a policy about when to use debconf It's a pity you ignore the express wishes of the author, and the consensus on this list as to their use. * To set up stunnel for server use, read the /usr/share/doc/stunnel/README.Debian file. If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. -- see shy jo pgpHKWbC3pyy8.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Thursday 03 July 2003 22:49, Joey Hess wrote: Julien LEMOINE wrote: Finally, since there is not really a policy about when to use debconf It's a pity you ignore the express wishes of the author, and the consensus on this list as to their use. I ignore nothing and nobody, I read all reply of this thread. But I have to take a decision for this problem. It is simple to say don't break anything, but in this case this seem very difficult to make a consensus. * To set up stunnel for server use, read the /usr/share/doc/stunnel/README.Debian file. If I ever add filtering to the notes debconf allows to be displayed, notes that refer the user to README.Debian will be at the top of the list to never be displayed. Of course, I am much more likely to bow to the pressure of notes like the one you're apparently adding, and completly disable all notes at some point, rather than adding filtering. I don't like arms races. Stunnel version with debconf warning is ready but I did not uploaded it, I don't want to disappoint users or create a new debate on debconf use. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf : Conclusion
On Thursday 03 July 2003 21:36, Steve Langasek wrote: On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: First of all, I present my excuses for having started a new debate about debconf in debian-devel. Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. It is not your responsibility to fix all of upstream's bugs, but it *is* your responsibility to protect Debian users from upstream breakage as much as possible. This upstream change makes no sense from a usability standpoint; this new stunnel package would be pretty useless to me, and I wouldn't want to have it automatically installed on my systems if I were using the previous, working version. By the time a debconf note is sent, it's too late. What do you propose ? Do you think Debian must keep old version of stunnel (3.x) for compatibility and do not include new version ? Best Regards -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf : Conclusion
Hi On Thursday 03 July 2003 19:37, Thomas Viehmann wrote: Julien LEMOINE wrote: Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. Yes. But you still have the options of: - Publically asking if someone else has time and skill to do it. - Putting off the update and/or packaging the interface incompatible stunnel under a new name. Yes, this is a good solution. It is a little too late now but I will use this method for the next problem of this kind. Finally, since there is not really a policy about when to use debconf, I will respect the DFSG [1] and add a debconf warning [2] in the stunnel package. There is a difference between the social contract and the DFSG. As a user of stunnel: Your warning will not help me as it does not keep stunnel from breaking. *Not* installing a totally incompatible program where the stunnel I wanted when I said apt-get install stunnel would. I did not upload it. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:06:26AM +0200, Julien LEMOINE wrote: On Thursday 03 July 2003 21:36, Steve Langasek wrote: On Thu, Jul 03, 2003 at 04:17:50PM +0200, Julien LEMOINE wrote: First of all, I present my excuses for having started a new debate about debconf in debian-devel. Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. It is not your responsibility to fix all of upstream's bugs, but it *is* your responsibility to protect Debian users from upstream breakage as much as possible. This upstream change makes no sense from a usability standpoint; this new stunnel package would be pretty useless to me, and I wouldn't want to have it automatically installed on my systems if I were using the previous, working version. By the time a debconf note is sent, it's too late. What do you propose ? Do you think Debian must keep old version of stunnel (3.x) for compatibility Given how it sounds like upstream are completely incompetent and have decided to gratuitously break compatibility, that sounds like a good idea. and do not include new version ? Why wouldn't you include the new version as well? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpYYSMU3uH11.pgp Description: PGP signature
Re: Debconf or not debconf : Conclusion
On Friday 04 July 2003 01:52, Andrew Suffield wrote: What do you propose ? Do you think Debian must keep old version of stunnel (3.x) for compatibility Given how it sounds like upstream are completely incompetent and have decided to gratuitously break compatibility, that sounds like a good idea. and do not include new version ? Why wouldn't you include the new version as well? Yes, keep the two versions of stunnel is probably the right way to handle this problem. Now the problem is that stunnel is uploaded in version 4 on stunnel package. What is the correct way to reintroduce stunnel for compatibility reasons ? uploading a new stunnel3 package will not resolve the problem. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:10:32AM +0200, Julien LEMOINE wrote: On Thursday 03 July 2003 19:37, Thomas Viehmann wrote: Julien LEMOINE wrote: Secondly, to reply to every person who thinks I should have created a more user friendly migration who did not break backwards compatibility. My answer is that I have no time to implement command line support for stunnel 4.x. Yes. But you still have the options of: - Publically asking if someone else has time and skill to do it. - Putting off the update and/or packaging the interface incompatible stunnel under a new name. Yes, this is a good solution. It is a little too late now but I will use this method for the next problem of this kind. This issue would not attract so much attention if it was really too late. It's *not* too late -- sarge hasn't released yet, and every reasonable effort should be made to get this right for sarge. You still have several options for moving this forward in a way that serves users' interests: - petition upstream to re-introduce support for commandline options - issue a call for help to the development community asking for someone to implement this - roll back to the 3.x version of stunnel by using an epoch, and commit to supporting this version even if upstream won't - roll back to the 3.x version of stunnel by using an epoch, and upload stunnel 4 under a new package name, supporting stunnel only for RC fixes Warning a user that their system has been broken should be a last resort, after all other options have been exhausted. Regards, -- Steve Langasek postmodern programmer pgpXDT2F9ThWv.pgp Description: PGP signature
Re: Debconf or not debconf
On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). It's a bit rude to break people's systems without warning them about it. Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? What makes you think that a debconf note is inappropriate for this? It appears to be quite a common thing to do and seems helpful. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpyvQ7YbxCim.pgp Description: PGP signature
Re: Debconf or not debconf
Julien LEMOINE [EMAIL PROTECTED] wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Is this just the usual default file for modifying the init-script's behaviour, i.e. will the package just continue to work as it did if the user does not know about it? If yes, perhaps a comment in the init-script would be helpful. cu andreas
Re: Debconf or not debconf
On Tue, Jul 01, 2003 at 09:17:40PM +0200, Artur R. Czechowski wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Important changes should be announced to user during installation/upgrade. Some of the packages complying with this tradition are: ssh, inn2. Ssh doing it with debconf. debconf notes are a major hassle. I'd prefer to get rid of a fair amount of ssh's use of debconf. -- Colin Watson [EMAIL PROTECTED]
Re: Debconf or not debconf
On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? It does not belong in debconf. Put it in the changelog -- users who want to know what's changing on their system should be looking there anyway, and tools such as apt-listchanges make it easier and ever to access changelog information. Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... -- Steve Langasek postmodern programmer pgpPkVF0ayfue.pgp Description: PGP signature
Re: Debconf or not debconf
On Tuesday 01 July 2003 17:12, Julien LEMOINE wrote: Hello, I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Please, please, please do not contribute to the flood of debconf messages; your feeling is right here. changelog is just fine - personally, I'd wish for apt-listchanges to be installed by default. cheers -- vbi -- random link of the day: http://fortytwo.ch/sienapei/uyaijaho pgpDSKSamWWX5.pgp Description: signature
Re: Debconf or not debconf
Mark Brown [EMAIL PROTECTED] wrote:
Since debconf is not really appreciated for this use, what is the best
solution ? Inform users with debconf or give them informations only in
changelog and README.Debian ?
What makes you think that a debconf note is inappropriate for this? It
appears to be quite a common thing to do and seems helpful.
Just because lots of people are doing it doesn't mean that it's good
practice.
I for one am sick and tired of useless Debconf messages popping up
during installation or being sent to me via email when I'm upgrading
hundreds of machines automatically.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debconf or not debconf
Hello, On Tuesday 01 July 2003 22:51, Andreas Metzler wrote: Julien LEMOINE [EMAIL PROTECTED] wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Is this just the usual default file for modifying the init-script's behaviour, i.e. will the package just continue to work as it did if the user does not know about it? Not exactly, there is a variable ENABLED which is set to 0 at installation. So the service will not start while variable is not set to 1. Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Debconf or not debconf
On Tue, Jul 01, 2003 at 08:40:02PM -0500, Steve Langasek wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? It does not belong in debconf. Put it in the changelog -- users who want to know what's changing on their system should be looking there anyway, and tools such as apt-listchanges make it easier and ever to access changelog information. This kind of thing would go in the hypothetical NEWS.Debian, but unfortunately I haven't gotten around to implementing support for it in apt-listchanges yet. -- - mdz
Re: Debconf or not debconf
On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. Jim Penny -- Steve Langasek postmodern programmer
Re: Debconf or not debconf
On Tue, Jul 01, 2003 at 08:40:02PM -0500, Steve Langasek wrote: It does not belong in debconf. Put it in the changelog -- users who want to know what's changing on their system should be looking there anyway, and tools such as apt-listchanges make it easier and ever to access changelog information. The changelog is really not a good way of telling users about changes like this, particularly when you consider things like upgrades between different stable versions. It's a non-default thing to have it visible during upgrades and it's very easy to get vast quanitities of information displayed with more important things like this getting lost in the flow. Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... I do agree with this - if we've got a flood of messages saying that the existing configuration has been broken then we ought to be looking at ways to avoid doing that, particularly in cases like this where there isn't something like a new upstream configuration format to handle. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Debconf or not debconf
Mark Brown wrote: What makes you think that a debconf note is inappropriate for this? It appears to be quite a common thing to do and seems helpful. Because it's documented and has been discussed to death on devel that debconf neither is a registry nor system for displaying random notes. [0] Cheers T. 0. e.g.: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01248.html pgpcgIiQZS5mJ.pgp Description: PGP signature
Re: Debconf or not debconf
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Jul 2003, Herbert Xu wrote: I for one am sick and tired of useless Debconf messages popping up during installation or being sent to me via email when I'm upgrading hundreds of machines automatically. Would you prefer the old way of STDOUT with a hold prompt? - -- FINE, I take it back: UNfuck you! Who is John Galt? [EMAIL PROTECTED], that's who! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQE/A0Hu+ZSKG3nWr3ARAl1SAJ0d8E9nrEwCIxduiWCYAaE6OOIDrQCgyUf3 FaRH2jyFLJrFgmStmomRV3s= =o3nt -END PGP SIGNATURE-
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 10:50:29AM -0400, Jim Penny wrote: On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? -- Steve Langasek postmodern programmer pgpHgC5wVmi5E.pgp Description: PGP signature
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 07:52:10PM +1000, Herbert Xu wrote: Mark Brown [EMAIL PROTECTED] wrote: What makes you think that a debconf note is inappropriate for this? It appears to be quite a common thing to do and seems helpful. Just because lots of people are doing it doesn't mean that it's good practice. Equally well, it's really nasty to break the user system and not warn them about it and there aren't many options for warning people. When you're upgrading hundreds of packages or sometimes not restarting programs for extended periods of time it can be hard to work out why something's gone wrong later on when you finally notice the problem. The first choice should, of course, be to avoid introducing changes that cause problems but if you're forced to do it the least you can do is tell users about it. One of the things that Debian has been impressively good at is providing smooth upgrades that don't bite you with nasty surprises. It would be unfortunate to see that change. I for one am sick and tired of useless Debconf messages popping up during installation or being sent to me via email when I'm upgrading hundreds of machines automatically. It would be useful for many of these notes if the support for central configuration that was discussed when Debconf was designed were implemented - part of the thing here is that the system still really expects machines to get individual care and feeding. Of course, this is a non trivial task and I'm not likely to work on it myself. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Debconf or not debconf
Julien LEMOINE wrote: Not exactly, there is a variable ENABLED which is set to 0 at installation. So the service will not start while variable is not set to 1. Well the user should notice this then and look in the README.Debian and changelog. If it's the only problem, however, it might be worth considering detecting whether or not the user configured stunnel in a way that it should be enabled and doing so automatically. Cheers T. pgpJLKOsFDdbE.pgp Description: PGP signature
Re: Debconf or not debconf
On Wed, 2 Jul 2003 15:57:01 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Wed, Jul 02, 2003 at 10:50:29AM -0400, Jim Penny wrote: On Tue, 1 Jul 2003 20:40:02 -0500 Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote: I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? Does the introduction of /etc/default/stunnel break a large percentage of installed systems? If so, I would recommend looking for a way to provide a more graceful upgrade -- this is worth much more than a note telling users that you've just broken their systems... It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. While it is indeed preferable to not break things, there are times when avoiding breakage is quite difficult. This appears, to me, to be one of those times. I was aware of the issue, because I had looked at the upgrade for Windows users. I still got mildly bitten by this upgrade. I would prefer to have a hard stop message. Jim Penny
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 06:34:53PM -0400, Jim Penny wrote: It breaks 100% of stunnel installations. The old stunnel was command line oriented, the current one is configuration file oriented. It would be very difficult to write a converter. I am going to disagree with most responders here. I think that in the case that if upgrading a package introduces substantial risk of breakage, a debconf message is quite appropriate. When a security related package has high risk of breakage, it is urgent. Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. My original argument stands: we should not be telling our users that we broke their system, because we shouldn't be breaking it in the first place. In this instance, it sounds to me like a bout of upstream bogosity has resulted in a rather grave regression in the quality of the software. Why would it ever be a good idea to *not* give users the ability to control the program using commandline options? Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. This is still a stupid reason to break support for the previous method of configuration. A really sane person has better things to worry about than whether someone logged into his server can see where a given SSL tunnel is forwarding to. Things like, not having his system broken by software upgrades. While it is indeed preferable to not break things, there are times when avoiding breakage is quite difficult. This appears, to me, to be one of those times. Not to me. -- Steve Langasek postmodern programmer pgpompCzBN07L.pgp Description: PGP signature
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 01:41:13PM +0200, Julien LEMOINE wrote: Not exactly, there is a variable ENABLED which is set to 0 at installation. So the service will not start while variable is not set to 1. So, just set the variable to 1 if upgrading from a version earlier than that in which you introduced that feature. - Sebastian
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 06:25:15PM +0100, Mark Brown wrote: Equally well, it's really nasty to break the user system and not warn them about it and there aren't many options for warning people. One of the things that Debian has been impressively good at is providing smooth upgrades that don't bite you with nasty surprises. It would be unfortunate to see that change. Somehow, you managed to miss the point entirely in your first line, *even though* you restated it later. You have assumed that it is ok to break the user system and warn people about it. It is not. Do not break the user system. Then no warnings are necessary. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpW7OSzuLXYv.pgp Description: PGP signature
Re: Debconf or not debconf
Jim Penny wrote: Now, this breakage happens to be somewhat benign, in that without configuration, it does not function at all. But it is also somewhat difficult to test for many uses. Further, when the unconfigured system fails to start, the failure is completely silent. This adds to the problems. What is difficult to test in ssl connections fail? I routinely test mine with telnet-ssl or python scripts (though I remember something about python and IMAP SSL not too long ago)... Also, the silentness would IMHO be better fixed by adding a big fat NOT to the init script (although anything more than a NOT will be controversial as well...). Reminds me of something I should fix for my packages... Cheers T. pgp8GOTOWRxD5.pgp Description: PGP signature
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 02:34:50PM -0600, John Galt wrote:
On Wed, 2 Jul 2003, Herbert Xu wrote:
I for one am sick and tired of useless Debconf messages popping up
during installation or being sent to me via email when I'm upgrading
hundreds of machines automatically.
Would you prefer the old way of STDOUT with a hold prompt?
I'd prefer no interaction at all during installation. I'm perfectly
able to read documenation thank you very much.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Debconf or not debconf
On Wed, 2003-07-02 at 14:00, Matt Zimmerman wrote: It does not belong in debconf. Put it in the changelog -- users who want to know what's changing on their system should be looking there anyway, and tools such as apt-listchanges make it easier and ever to access changelog information. This kind of thing would go in the hypothetical NEWS.Debian, but unfortunately I haven't gotten around to implementing support for it in apt-listchanges yet. Having just implemented support for NEWS.Debian in apt-listchanges (see 192089), and being generally against debconf notes, I disagree that in this case debconf should be avoided. This is not news; it requires changes from the system administrator. Joey Hess has mentioned, and I agree (see 199722), that debconf notes should really be named (and should always be interpreted as) warnings. One example we discussed during Debconf 2 was that of database software which, because of a format switch, requires a dump and re-load. In that case a warning is all you can provide, as there is no way to automatically find and convert all databases on a machine. This is a similar situation. There is, by the admission of the maintainer, no good way to convert between the 'old way' of running stunnel and the new way. Should this truly be the case, debconf should be used to warn the admin that stunnel will need configuration changes before it will function. Now, I agree that there should be some method of not breaking the configuration. But, if there truly is no way to avoid breakage, Debconf is the correct method of informing the administrator of this fact.
Re: Debconf or not debconf
On Wed, 2003-07-02 at 17:23, Herbert Xu wrote: I'd prefer no interaction at all during installation. I'm perfectly able to read documenation thank you very much. Happily, the noninteractive debconf frontend exists.
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 08:53:57PM -0400, Joe Drew wrote: On Wed, 2003-07-02 at 14:00, Matt Zimmerman wrote: This kind of thing would go in the hypothetical NEWS.Debian, but unfortunately I haven't gotten around to implementing support for it in apt-listchanges yet. Having just implemented support for NEWS.Debian in apt-listchanges (see 192089), and being generally against debconf notes, I disagree that in this case debconf should be avoided. This is not news; it requires changes from the system administrator. This is a similar situation. There is, by the admission of the maintainer, no good way to convert between the 'old way' of running stunnel and the new way. Should this truly be the case, debconf should be used to warn the admin that stunnel will need configuration changes before it will function. I confess to not having looked at the original example in detail. My feeling is that only items which require operator intervention, or otherwise will cause things to unavoidably break, should be displayed as notes. This seems to fall in this category. It is a common mistake, for some reason, to display this kind of note without checking to see whether the user is upgrading from an older version. I have seen several notes like this displayed on initial installation, and I find it very disruptive. In particular, the binutils warning displayed every time I install woody. -- - mdz
Re: Debconf or not debconf
On Wed, Jul 02, 2003 at 06:34:53PM -0400, Jim Penny wrote: Because of security considerations. The configuration file is read on startup, and then stunnel chroots away, so that it is no longer visible. The command line interface leaked information, internal IP structure, internal ports, etc. that a really paranoid person might prefer not be visible. I do not see how this change helps the situation. If there was previously a command line interface, and this was removed, that is not enabling the user to do anything new. Adding the configuration file functionality allows the user to do something they previously could not, but it doesn't seem necessary to remove other functionality in order to accomplish this. -- - mdz
Re: Debconf or not debconf
On Tue, 1 Jul 2003, Julien LEMOINE wrote: Hello, I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? debian/changelog
Re: Debconf or not debconf
Hello
On Tue, Jul 01, 2003 at 05:12:22PM +0200, Julien LEMOINE wrote:
Since debconf is not really appreciated for this use, what is the best
solution ? Inform users with debconf or give them informations only in
changelog and README.Debian ?
Important changes should be announced to user during installation/upgrade.
Some of the packages complying with this tradition are: ssh, inn2.
Ssh doing it with debconf. Inn2 first did it echoing text from
{pre,post}inst scripts and waiting for user interaction, but now it also
uses a debconf. Big positive is ability to easy localization of debconf
templates. Those templates are available to translation
at http://ddtp.debian.org.
Regards
Artur
--
#gaduly to jak wenezuelski serial. Niewane, ile odcinkw opucisz
zawsze bdziesz na czasie
/Czesiu/
Re: Debconf or not debconf
* Julien LEMOINE I received a bug report on stunnel package from an user [1] that complained about the fact that I didn't warning about the new /etc/default/stunnel file introduced in package (thereis a note in README.Debian and in changelog). Since debconf is not really appreciated for this use, what is the best solution ? Inform users with debconf or give them informations only in changelog and README.Debian ? I'd say you stick it in debian/NEWS and leave it at that. If you're in doubt of whether or to use debconf for anything: don't. Far too many packages has become far too loquacious of late, and the (mis)use of debconf seem to be misinterpreted as a carte blanche for doing so, unfortunately. -- Tore Anderson
Re: Debconf LDAP (Was: Debconf question)
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Turbo Fredriksson wrote: Ahh, I see... I was looking through the sources a little, but i couldn't find the 'main file' so to speak... :) How much is done, need any help? We need it at work, and i can do much of this on 'official company time' :) Joey There's a big hole in the spec debconf implements, where the Joey specification of the backend database should be. That hole Joey needs to be plugged, but going in and writing code is not Joey the answer, we need a design. Ofcource... 'Design first, code later' is my middle name... Usually :) Where's the design specs of the rest of the system so far? -- NORAD Delta Force Nazi Mossad Ortega explosion radar terrorist [Hello to all my fans in domestic surveillance] strategic supercomputer cracking Clinton SDI fissionable
Re: Debconf LDAP (Was: Debconf question)
Turbo Fredriksson wrote: Where's the design specs of the rest of the system so far? http://kitenet.net/doc/debconf/specification.html -- see shy jo
Re: Debconf LDAP (Was: Debconf question)
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Turbo Fredriksson wrote: Where's the design specs of the rest of the system so far? Joey http://kitenet.net/doc/debconf/specification.html I'll have a look at it, and see what I can come up with... -- nuclear Saddam Hussein strategic AK-47 Mossad Khaddafi BATF Nazi supercomputer colonel explosion Honduras NSA Marxist World Trade Center
Re: Debconf LDAP (Was: Debconf question)
Previously Turbo Fredriksson wrote: I'll have a look at it, and see what I can come up with... Be warned that I reasonably know what I would like to see there and there is already code (gconf) which implements it. I really need to check what the build and runtime-dependencies for gconf are though, I haven't looked at it in a while :(. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | pgpY0GX3KHama.pgp Description: PGP signature
Re: Debconf LDAP (Was: Debconf question)
Turbo Fredriksson wrote: When reading the doc's for debconf, I saw that it should be possible to have the config in a LDAP database... Exactly is this supposed to get to work? Debconf doesn't support any backend database yet, however once it does ldap is a pretty good fit. -- see shy jo
Re: Debconf LDAP (Was: Debconf question)
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Turbo Fredriksson wrote: When reading the doc's for debconf, I saw that it should be possible to have the config in a LDAP database... Exactly is this supposed to get to work? Joey Debconf doesn't support any backend database yet, however Joey once it does ldap is a pretty good fit. Ahh, I see... I was looking through the sources a little, but i couldn't find the 'main file' so to speak... :) How much is done, need any help? We need it at work, and i can do much of this on 'official company time' :) -- plutonium cracking jihad South Africa FSF Noriega security nuclear North Korea assassination KGB smuggle fissionable NSA Kennedy
Re: Debconf LDAP (Was: Debconf question)
Turbo Fredriksson wrote: Ahh, I see... I was looking through the sources a little, but i couldn't find the 'main file' so to speak... :) How much is done, need any help? We need it at work, and i can do much of this on 'official company time' :) There's a big hole in the spec debconf implements, where the specification of the backend database should be. That hole needs to be plugged, but going in and writing code is not the answer, we need a design. -- see shy jo
