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
Debconf or not debconf : Conclusion
Hello, 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. 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. Thanks for all your comments. Best Regards. [1] 4. Our Priorities are Our Users and Free Software [2] Description: general notes about stunnel * stunnel 4.x does not support any more command line arguments, so you need to edit /etc/stunnel.conf by hand if you are upgrading from stunnel 3.x * For stunnel versions = 4.04-4, the file /etc/default/stunnel is provided and you need to set ENABLED=1 to allow stunnel to be started from init.d * To set up stunnel for server use, read the /usr/share/doc/stunnel/README.Debian file. -- Julien LEMOINE / SpeedBlue
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 : 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 : 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
