On Tue, Jul 29, 2003 at 01:32:39PM +0200, Gerfried Fuchs wrote:
has been in europe and 2004 should be on a different continent (Asia,
America, Australia -- there are many nice places that start with A :-)
I would love to see another debconf in North America because I was unable to
make
. 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
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
, 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
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
. 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
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
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
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
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:
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
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
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.
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
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
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
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
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
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
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
Re: Re: [devel] Debconf or not debconf [Jim Penny [EMAIL PROTECTED], Wed, Jul
02, 2003 at 10:50:29AM -0400, [EMAIL PROTECTED]]
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
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
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
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
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
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
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
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
#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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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 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
).
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
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
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
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
/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
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
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
-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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
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
).
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
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
* 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
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
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
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
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
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?
--
Nazi Treasury quiche NORAD Noriega assassination KGB Peking Ft. Bragg
Khaddafi North Korea jihad fissionable genetic radar
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
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
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
81 matches
Mail list logo
