Perhaps it would, if it had not come on the tails of a string of
unwarranted
insults against other developers (most of whom seem to agree with my ideas
on the technical subject under discussion).
The closest I got to an insult was accusing Manoj of having a prune up his
rear. In comparison I
On Mon, Apr 21, 2003 at 11:21:59AM +0100, Matt Ryan wrote:
Perhaps it would, if it had not come on the tails of a string of
unwarranted
insults against other developers (most of whom seem to agree with my
ideas on the technical subject under discussion).
The closest I got to an insult
On Mon, 21 Apr 2003 11:21:59 +0100, Matt Ryan [EMAIL PROTECTED] said:
All I have said to date is that the overwrite question was suggested
in the past by another developer as a way of dealing with the
problem when it came up before. Some of us implemented the
suggestion and it seems no one
On Mon, 21 Apr 2003 11:15:46 -0400, Matt Zimmerman [EMAIL PROTECTED] said:
On Mon, Apr 21, 2003 at 11:21:59AM +0100, Matt Ryan wrote:
Perhaps it would, if it had not come on the tails of a string of
unwarranted
insults against other developers (most of whom seem to agree with
my ideas on
Unfortunately your choice is rather weak and doesn't back up your argument
so I feel obliged to continue the thread a bit further (plus its giving my
brain some exercise).
[Oh yeah, the quotes are from some developer who's name I've promised not to
use in my emails]
...and telling Ben Collins
On Mon, Apr 21, 2003 at 06:33:49PM +0100, Matt Ryan wrote:
[more of the same]
Plonk.
--
- mdz
* Matt Ryan ([EMAIL PROTECTED]) wrote:
There are no ranks in Debian, no one gets paid (AFAIK) and so no view is
more or less valid than another. I think a small minority of developers can
easily get identified as pushing their own agendas if we did an informal
poll on this list. Those are the
On Mon, Apr 21, 2003 at 06:33:49PM +0100, Matt Ryan wrote:
And the bit that the jumped up developers don't seem to understand is the
co-operation and consensus. I constantly see comments on how we should
restrict the number of maintainers, how we need to make sure everyone's
packages measures
Matt Ryan [EMAIL PROTECTED] writes:
Unfortunately your choice is rather weak and doesn't back up your
argument so I feel obliged to continue the thread a bit further
(plus its giving my brain some exercise).
[Oh yeah, the quotes are from some developer who's name I've
promised not to use
Emile van Bergen [EMAIL PROTECTED] writes:
In most cases, the only feature that's used (and needed) of XML that it
stores a tree of attribute/value pairs.
Given limited effort, I am absolutely convinced that it should be
possible to come up with a more robust, well defined, simple(!), user
On Sat, 19 Apr 2003 19:33:21 -0400,
Matt Zimmerman [EMAIL PROTECTED] said:
As was explained in detail, in order to do anything useful with
that information, it is necessary to be able to show the user the
proposed changes to the configuration file. It is completely
unhelpful to say:
On Sat, 19 Apr 2003 20:21:14 +0100,
Matt Ryan [EMAIL PROTECTED] said:
Secondly, this isnot a witch hunt. What is being done is that a
policy violation in older practice is being pointed
out. Alternatives are being discussed; a witch hunt would have
involved mass RC bug filings.
The
On Sun, Apr 20, 2003 at 02:45:32AM -0500, Manoj Srivastava wrote:
Hmm. ucf does show the user the changes, and even offers to
merge maintainer changes into the current configuration file.
What functionality do you think ucf is missing?
In my first message, I listed bullet
On Sun, 20 Apr 2003 12:22:31 -0400,
Matt Zimmerman [EMAIL PROTECTED] said:
On Sun, Apr 20, 2003 at 02:45:32AM -0500, Manoj Srivastava wrote:
Hmm. ucf does show the user the changes, and even offers to merge
maintainer changes into the current configuration file.
What functionality do
On Sun, Apr 20, 2003 at 12:59:27PM -0500, Manoj Srivastava wrote:
On Sun, 20 Apr 2003 12:22:31 -0400,
Matt Zimmerman [EMAIL PROTECTED] said:
In my first message, I listed bullet points for goals, most of
which ucf meets, and then outlined the problems with this model,
and linked to
ucf still has the same fundamental problem with regard to preconfiguration,
which was the primary issue that I raised in my original message. The
consensus, as I recall, was that preconfiguration is important, and that
prompting in postinst should be minimized.
I may have missed something
On Sun, Apr 20, 2003 at 09:48:48PM +0300, Jarno Elonen wrote:
ucf still has the same fundamental problem with regard to
preconfiguration, which was the primary issue that I raised in my
original message. The consensus, as I recall, was that preconfiguration
is important, and that
What is not helpful is when a developer gets a bad case of NOMUS
(Not On My UNIX System) and goes off on one about how perfectly the
world would be if everyone agreed with their narrow definition of
the 'correct' way to do things. The recent /run debate was another
example of this
On Sun, 20 Apr 2003 21:48:48 +0300, Jarno Elonen [EMAIL PROTECTED] said:
ucf still has the same fundamental problem with regard to
preconfiguration, which was the primary issue that I raised in my
original message. The consensus, as I recall, was that
preconfiguration is important, and that
On Sun, Apr 20, 2003 at 09:06:38PM +0100, Matt Ryan wrote:
Eventually someone (MDZ seems to be starting this again) will come up with
Please avoid using my name in support of your arguments. I rather not be
associated with your recent publicity.
--
- mdz
I may have missed something but why can't the changed/merged
configuration files be saved somewhere in preinstall phase
[...]
Again: see my first message and followups for a specific, concrete example
of why this won't work.
Thanks, I read the thread. So the reason was that configuration
On Sun, 20 Apr 2003 21:06:38 +0100, Matt Ryan [EMAIL PROTECTED] said:
I never suggested to throw out policy (perhaps you should revisit my
email). All I said was that this was prior best practice and now we
might make a change.
Any prior practice that promotes not preserving user
I may have missed something but why can't the changed/merged
configuration files be saved somewhere in preinstall phase and the
[...]
Well, for configuration files that require the unpacked
package to generate, you can't ask during preconfiguration. For files
created using non
On Sun, 20 Apr 2003 23:49:50 +0300, Jarno Elonen [EMAIL PROTECTED] said:
Thanks, I read the thread. So the reason was that configuration file
generation is mostly done in postinst scripts? I didn't quite get
why it couldn't in practically all cases be done in preinst (or even
a completely
I demand that Matt Zimmerman may or may not have written...
On Sun, Apr 20, 2003 at 09:06:38PM +0100, Matt Ryan wrote:
Eventually someone (MDZ seems to be starting this again) will come up with
Come up with what?
Let's restore some context...
a sensible solution (that doesn't predepend on
On Sun, Apr 20, 2003 at 11:22:48PM +0100, Darren Salt wrote:
Ahem. From here, given that reference to a sensible solution and your
proposed handling posting (which looks like it'll become Something
Useful), that looks like look, things are heading in the right direction
again.
Perhaps it
From: Manoj Srivastava [EMAIL PROTECTED]
Subject: Re: stop the manage with debconf madness
Date: Sun, 20 Apr 2003 02:58:10 -0500
(on the whole) try to make the best job they can of the packaging
of their programs.
Anyone can make mistakes.
Yes and you can too, further policy can
On Mon, 21 Apr 2003 09:57:41 +0900 (JST), Atsuhito Kohda
[EMAIL PROTECTED] said:
From: Manoj Srivastava [EMAIL PROTECTED] Subject: Re: stop the
manage with debconf madness Date: Sun, 20 Apr 2003 02:58:10 -0500
(on the whole) try to make the best job they can of the packaging
Personally I use the ask-about-overwrite question in debconf because the
last time this thread came up the only sensible solution was put forward in
the attached email. Now, I'm all for a better solution when it is determined
what that is, *but* I'm not for a witch hunt based on what was seen to
On 18-Apr-03, 10:28 (CDT), Steve Langasek [EMAIL PROTECTED] wrote:
If the package maintainers are correctly using the debconf priorities,
and the admin has chosen a debconf priority that accurately reflects
their preferences, why do you care? By definition, any prompts at
priority medium or
On Sat, 19 Apr 2003 14:07:04 +0100,
Matt Ryan [EMAIL PROTECTED] said:
Personally I use the ask-about-overwrite question in debconf
because the last time this thread came up the only sensible
solution was put forward in the attached email. Now, I'm all for a
better solution when it is
On Sat, Apr 19, 2003 at 11:11:59AM -0500, Steve Greenland wrote:
On 18-Apr-03, 10:28 (CDT), Steve Langasek [EMAIL PROTECTED] wrote:
If the package maintainers are correctly using the debconf priorities,
and the admin has chosen a debconf priority that accurately reflects
their preferences,
On Sat, Apr 19, 2003 at 02:07:04PM +0100, Matt Ryan wrote:
Personally I use the ask-about-overwrite question in debconf because the
last time this thread came up the only sensible solution was put forward
in the attached email. Now, I'm all for a better solution when it is
determined what
Secondly, this isnot a witch hunt. What is being done is that
a policy violation in older practice is being pointed
out. Alternatives are being discussed; a witch hunt would have
involved mass RC bug filings.
The TEX discussion is definitely in witchunt territory. Maintainers (on the
* Matt Zimmerman
There was a more recent discussion about the same idea. A summary of the
goals:
- Don't try to parse every program's configuration file format
- Notice that a non-conffile, autogenerated configuration file has been
modified by the user, and don't lose their
On Sat, 2003-04-19 at 15:41, Tore Anderson wrote:
cat _eof /usr/share/fnord/managed-conffiles/fnord.cf
/var
signature.asc
Description: This is a digitally signed message part
On Sat, Apr 19, 2003 at 09:41:58PM +0200, Tore Anderson wrote:
Hey, you just described how how ucf can be used.
I am aware of ucf. I described some things that ucf does, and some things
that it does not.
Lo and behold! We've just achieved your goals, using tools already in
the
* Matt Zimmerman
Did you read my sample configuration scenario (xserver-xfree86),
or the threads that I referenced? They explain in more detail.
I did, and I can't see why ucf can't be done for this purpose,
too;
As I said, I am suggesting we mimick the conffile mechanism. conffiles
On Sun, Apr 20, 2003 at 01:05:18AM +0200, Tore Anderson wrote:
As far as I know, ucf is created exactly for this purpose; to mimic
dpkg's conffile handing. I assume you want to know if the configuration
file is unmodified prior to asking all the debconf questions, and making
use of
On Sat, Apr 19, 2003 at 03:14:34PM -0400, Matt Zimmerman wrote:
- Provide 3-way merge functionality to incorporate changes without losing
modifications in the common case (I hear this is coming for conffiles as
well)
Great!
Actually what I would like (and is similar in ways to the above)
* Matt Zimmerman
As was explained in detail, in order to do anything useful with that
information, it is necessary to be able to show the user the proposed
changes to the configuration file. It is completely unhelpful to say:
You have modified this configuration file, and it has also
On Sun, Apr 20, 2003 at 02:20:00AM +0200, Tore Anderson wrote:
* Matt Zimmerman
As was explained in detail, in order to do anything useful with that
information, it is necessary to be able to show the user the proposed
changes to the configuration file. It is completely unhelpful to
* Tore Anderson
I see your problem when you insist on asking on asking all questions
at the configure stage -- personally, I don't think delaying the actual
generating of the configuration file (and asking the question about
overwriting the old file) to the postinst stage is *that*
On Sun, Apr 20, 2003 at 04:11:29AM +0200, Tore Anderson wrote:
I fully agree that as many questions as possible should be asked before
unpacking the package. And I also agree it would better if the replace
the configuration file questions also came at that point of the
upgrade, but
Hi,
On Thu, Apr 17, 2003 at 09:45:54AM -0700, Craig Dickson wrote:
Andrew Suffield wrote:
On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote:
On Thursday 17 April 2003 02:32, Colin Walters wrote:
On Wed, 2003-04-16 at 20:21, Chris Hanson wrote:
I'd rather fix this
On 16-Apr-03, 18:08 (CDT), Colin Walters [EMAIL PROTECTED] wrote:
Debconf is NOT a license to overwrite user's configurations!
You've correctly identified the problem.
I propose a different solution to this problem, which conforms much more
with policy, while still allowing debconf to be
On Fri, Apr 18, 2003 at 09:28:07AM -0500, Steve Greenland wrote:
On 16-Apr-03, 18:08 (CDT), Colin Walters [EMAIL PROTECTED] wrote:
Debconf is NOT a license to overwrite user's configurations!
You've correctly identified the problem.
I propose a different solution to this problem, which
On Fri, 2003-04-18 at 10:28, Steve Greenland wrote:
I propose a different solution to this problem, which conforms much more
with policy, while still allowing debconf to be used as much as
possible.
But that's not the solution.
Yep, I agree completely. So let's talk about solutions.
On Fri, 18 Apr 2003 10:28:57 -0500,
Steve Langasek [EMAIL PROTECTED] said:
If the package maintainers are correctly using the debconf
priorities, and the admin has chosen a debconf priority that
accurately reflects their preferences, why do you care? By
definition, any prompts at
On 18 Apr 2003 11:55:09 -0400,
Colin Walters [EMAIL PROTECTED] said:
So, opinions? Yeah, it's kind of gross. But the way things are
now is far worse.
As long as /etc/conffiles/managed, /etc/conffiles/unmanaged,
and /etc/conffiles/default are never themselves unmanaged, this
Colin Walters writes:
One might be to create a third class of configuration files; let's call
them managed configuration files.
Is the choice to be up to the maintainer? If so, I'm afraid that over time
almost all configfiles would become managed, as that would be the easy way
for maintainers.
On Fri, 18 Apr 2003 14:04:25 -0500,
John Hasler [EMAIL PROTECTED] said:
Colin Walters writes:
One might be to create a third class of configuration files; let's
call them managed configuration files.
Is the choice to be up to the maintainer? If so, I'm afraid that
over time almost
On Fri, 2003-04-18 at 15:04, John Hasler wrote:
Colin Walters writes:
One might be to create a third class of configuration files; let's call
them managed configuration files.
Is the choice to be up to the maintainer? If so, I'm afraid that over time
almost all configfiles would become
On Fri, 2003-04-18 at 13:54, Manoj Srivastava wrote:
On 18 Apr 2003 11:55:09 -0400,
Colin Walters [EMAIL PROTECTED] said:
So, opinions? Yeah, it's kind of gross. But the way things are
now is far worse.
As long as /etc/conffiles/managed, /etc/conffiles/unmanaged,
and
Would it already be time for a long term solution that no doubt has been
discussed sometimes in the past:
looking at configuration files in /etc and ~/.*, most of them are actually
very simple. Instead of treating them as flat files with arbitrary content
and *generating* the managed ones from
On Fri Apr 18, 12:54pm -0500, Manoj Srivastava wrote:
On 18 Apr 2003 11:55:09 -0400,
Colin Walters [EMAIL PROTECTED] said:
So, opinions? Yeah, it's kind of gross. But the way things are
now is far worse.
As long as /etc/conffiles/managed, /etc/conffiles/unmanaged,
and
On Fri, Apr 18, 2003 at 05:06:15PM -0400, Colin Walters wrote:
On Fri, 2003-04-18 at 13:54, Manoj Srivastava wrote:
If we standardize on a easy to interpret format for these
files, I'll add the logic to ucf to handle these directives. (how
about a configuration file path per line for
On Fri, Apr 18, 2003 at 10:28:57AM -0500, Steve Langasek wrote:
If the package maintainers are correctly using the debconf priorities,
and the admin has chosen a debconf priority that accurately reflects
their preferences, why do you care? By definition, any prompts at
priority medium or
On Thu, 2003-04-17 at 01:08, Colin Walters wrote:
I just installed laptop-net, becuase it looked similar to something
I'd like to work on.
You might want to look at ifupdown-roaming too
http://panopticon.csustan.edu/thood/ifupdown-roaming.html
--
Thomas Hood [EMAIL PROTECTED]
On Thursday 17 April 2003 02:32, Colin Walters wrote:
On Wed, 2003-04-16 at 20:21, Chris Hanson wrote:
I'd rather fix this properly; what you suggest is a workaround. What
I consider a proper fix is to redefine the configuration files so that
they can be parsed. I have learned, the hard
On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote:
On Thursday 17 April 2003 02:32, Colin Walters wrote:
On Wed, 2003-04-16 at 20:21, Chris Hanson wrote:
I'd rather fix this properly; what you suggest is a workaround. What
I consider a proper fix is to redefine the
OTOH, xml config files (like fontconfig's config) could be losslessly
parsed
through xslt processing...
Much like any other config file can be losslessly parsed by processing
them. That's not really very helpful.
However, it could be something of a standard for configuration files,
Andrew Suffield wrote:
On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote:
On Thursday 17 April 2003 02:32, Colin Walters wrote:
On Wed, 2003-04-16 at 20:21, Chris Hanson wrote:
I'd rather fix this properly; what you suggest is a workaround. What
I consider a proper fix is
On Thu, 2003-04-17 at 06:47, Mike Hommey wrote:
OTOH, xml config files (like fontconfig's config) could be losslessly parsed
through xslt processing...
I know, but I haven't done this because expat (AFAICS) doesn't provide a
command-line tool to do XSLT, and Depend:ing on xsltproc (which uses
Package: laptop-net
Severity: serious
I just installed laptop-net, becuase it looked similar to something
I'd like to work on.
The first thing it asked me was whether I wanted to manage its
configuration file with Debconf, and it defaulted to yes!
This behavior needs to stop, now. It is a
Date: 16 Apr 2003 19:08:17 -0400
From: Colin Walters [EMAIL PROTECTED]
Package: laptop-net
Severity: serious
I just installed laptop-net, becuase it looked similar to
something I'd like to work on.
The first thing it asked me was whether I wanted to manage its
On Wed, 2003-04-16 at 20:21, Chris Hanson wrote:
I'd rather fix this properly; what you suggest is a workaround. What
I consider a proper fix is to redefine the configuration files so that
they can be parsed. I have learned, the hard way, that using shell
scripts for configuration files
67 matches
Mail list logo
