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
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 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
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,
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 soluti
>> 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 prompt
>> 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, t
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 maintaine
>> 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
> ove
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
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/unmanag
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/unmana
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 lin
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 l
Personally I use the ask-about-overwrite question in debconf because the
last time this thread came up the only sensible solution was put forward in
the attached email. Now, I'm all for a better solution when it is determined
what that is, *but* I'm not for a witch hunt based on what was seen to be
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 mediu
>> 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 whe
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 pref
> 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
wh
>> 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 fil
> > 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
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
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 use
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 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
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 mista
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 t
> 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
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
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
>>
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
confi
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 fil
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
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 conf
> > 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
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
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 use
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
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(!),
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 t
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 t
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 meas
"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
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
* 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 arch
* 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. conffile
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 o
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 a
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 unhelp
* 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 *t
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,
>> 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
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 po
> 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.
>>
>> W
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,
> 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
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,
> > 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 confi
> > 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 usi
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 complete
67 matches
Mail list logo