From: Tomas Szepe <szepe@pinerecords.com>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: a few more "make xconfig" inconsistencies
Date: Wed, 1 Jan 2003 15:51:20 +0100 [thread overview]
Message-ID: <20030101145120.GL14184@louise.pinerecords.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0301010922160.18348-100000@dell>
> [rpjday@mindspring.com]
>
> On Wed, 1 Jan 2003, Tomas Szepe wrote:
>
> > > [rpjday@mindspring.com]
> > >
> > > even if, under "Networking options", i deselect IPv6,
> > > i'm still presented with an inactive IPv6 Netfilter Configuration
> > > screen.
> >
> > This is fixed in both 2.4.20 & 2.5.53 as far as I can see.
>
> i'm looking at 2.4.20 with the 2.4.21-pre2 patch as we speak,
> and, under "make xconfig", after deselecting IPv6, i am still
> presented with a (deactivated) IPv6 netfilter configuration
> dialog.
Oh, I see what you mean. This behavior is a "feature" of the old
xconfig (it's been so since the 2.0 times or thereabouts). menuconfig
will hide entirely what xconfig merely grays out.
> granted, it's deactivated (is that what you were referring to?)
Right.
> but it's still presented to me. this seems to be inconsistent
> with one of your recent patches -- don't show arcnet dialog if
> arcnet is deselected.
That's just my word choice sucking noodles as usual. I should
probably be referring to these changes with something like "make
the submenu dependent on its parent entry," which wouldn't take
for granted any of the pecularities a certain config frontend
might throw in. You see, in 2.4, config, menuconfig and xconfig
all have their own mechanics for work with Config.in files.
(Ever noticed how menuconfig and xconfig produce different
.config's while the options chosen are identical?)
> am i understanding all this correctly?
Hope this clarifies.
> i'm downloading it as we speak. :-) but on a more general note,
> here's something i was thinking about -- some of the more general
> selections should have their overall select button moved up in
> the hierarchy.
Yes, but no one is really fond of the thought of the options getting
rearranged too much. There's the old "Yes, it's not ideal, but if
you woke me up totally wasted at 3 a.m., I'd know where to look for
CONFIG_HRM0PS54554."
> anyway, i'll switch over to 2.5.53 and let you know what i find.
Thanks.
--
Tomas Szepe <szepe@pinerecords.com>
next prev parent reply other threads:[~2003-01-01 14:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-01 14:05 a few more "make xconfig" inconsistencies Robert P. J. Day
2003-01-01 14:16 ` Tomas Szepe
2003-01-01 14:32 ` Robert P. J. Day
2003-01-01 14:45 ` John Bradford
2003-01-01 14:49 ` Robert P. J. Day
2003-01-01 14:57 ` Robert P. J. Day
2003-01-01 14:51 ` Tomas Szepe [this message]
2003-01-01 15:04 ` John Bradford
2003-01-01 15:11 ` Tomas Szepe
2003-01-01 15:24 ` John Bradford
2003-01-01 15:21 ` John Bradford
2003-01-01 15:24 ` Tomas Szepe
2003-01-01 16:08 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030101145120.GL14184@louise.pinerecords.com \
--to=szepe@pinerecords.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rpjday@mindspring.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox