Patchwork [2,of,9,v4] Config.in.legacy: update description for users

login
register
mail settings
Submitter Thomas De Schampheleire
Date Sept. 2, 2013, 8:07 p.m.
Message ID <ac4d080274a06689e8d4.1378152471@argentina>
Download mbox | patch
Permalink /patch/272059/
State Accepted
Commit cce5baa8ee8eb9bbe27448aa75b67719431bf9e9
Headers show

Comments

Thomas De Schampheleire - Sept. 2, 2013, 8:07 p.m.
This patch clarifies the message shown to users in the legacy menu.
It explicitly mentions the need to save the configuration before disabling the
legacy options.

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
v4: - reorder paragraphs (and modify text a bit to suit this new order)
    - add "Once you have removed all ..." sentence
    - add vertical whitespace (I used the least visible * symbol to preserve
      whitespace)
    (all comments from Arnout)
(v3): new patch in this series

 Config.in.legacy |  24 ++++++++++++++++++++----
 1 files changed, 20 insertions(+), 4 deletions(-)
Thomas Petazzoni - Sept. 2, 2013, 8:55 p.m.
Dear Thomas De Schampheleire,

On Mon, 02 Sep 2013 22:07:51 +0200, Thomas De Schampheleire wrote:

>  if BR2_LEGACY
>  comment "Your old configuration uses legacy options that no  "
> -comment "longer exist in buildroot.                          "
> -comment "Please look at the options which have been selected "
> -comment "and read their help text.                           "
> -comment "As long as these options stay selected, the build   "
> +comment "longer exist in buildroot, as indicated in the menu "
> +comment "below. As long as these options stay selected, or in"
> +comment "case of string options are non-empty, the build     "
>  comment "will fail.                                          "
> +comment "*                                                   "
> +comment "Where possible, an automatic conversion from old to "
> +comment "new symbols has been performed. Before making any   "
> +comment "change in this legacy menu, make sure to exit the   "
> +comment "configuration editor a first time and save the      "
> +comment "configuration. Otherwise, the automatic conversion  "
> +comment "of symbols will be lost.                            "

This really seems ugly for users, no? I know it's been discussed, but
can you summarize why this should be done by our users?

Thanks!

Thomas
Arnout Vandecappelle - Sept. 3, 2013, 6:16 a.m.
On 09/02/13 22:55, Thomas Petazzoni wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 02 Sep 2013 22:07:51 +0200, Thomas De Schampheleire wrote:
>
>>   if BR2_LEGACY
>>   comment "Your old configuration uses legacy options that no  "
>> -comment "longer exist in buildroot.                          "
>> -comment "Please look at the options which have been selected "
>> -comment "and read their help text.                           "
>> -comment "As long as these options stay selected, the build   "
>> +comment "longer exist in buildroot, as indicated in the menu "
>> +comment "below. As long as these options stay selected, or in"
>> +comment "case of string options are non-empty, the build     "
>>   comment "will fail.                                          "
>> +comment "*                                                   "
>> +comment "Where possible, an automatic conversion from old to "
>> +comment "new symbols has been performed. Before making any   "
>> +comment "change in this legacy menu, make sure to exit the   "
>> +comment "configuration editor a first time and save the      "
>> +comment "configuration. Otherwise, the automatic conversion  "
>> +comment "of symbols will be lost.                            "
>
> This really seems ugly for users, no? I know it's been discussed, but
> can you summarize why this should be done by our users?

  I.e., add "because of Kconfig limitations", right?

  Regards,
  Arnout
Thomas Petazzoni - Sept. 3, 2013, 7:18 a.m.
Dear Arnout Vandecappelle,

On Tue, 03 Sep 2013 08:16:04 +0200, Arnout Vandecappelle wrote:

> >>   if BR2_LEGACY
> >>   comment "Your old configuration uses legacy options that no  "
> >> -comment "longer exist in buildroot.                          "
> >> -comment "Please look at the options which have been selected "
> >> -comment "and read their help text.                           "
> >> -comment "As long as these options stay selected, the build   "
> >> +comment "longer exist in buildroot, as indicated in the menu "
> >> +comment "below. As long as these options stay selected, or in"
> >> +comment "case of string options are non-empty, the build     "
> >>   comment "will fail.                                          "
> >> +comment "*                                                   "
> >> +comment "Where possible, an automatic conversion from old to "
> >> +comment "new symbols has been performed. Before making any   "
> >> +comment "change in this legacy menu, make sure to exit the   "
> >> +comment "configuration editor a first time and save the      "
> >> +comment "configuration. Otherwise, the automatic conversion  "
> >> +comment "of symbols will be lost.                            "
> >
> > This really seems ugly for users, no? I know it's been discussed, but
> > can you summarize why this should be done by our users?
> 
>   I.e., add "because of Kconfig limitations", right?

That I understood, but for my own culture, can you summarize what are
those limitations? Maybe it would be good to document them in the big
fat comment inside Config.in.legacy (not the one shown to the user, but
the one inside the source code). Having to exit menuconfig, and restart
it doesn't seem like a really great thing, so I'd like to understand
why we need that, and what are our options to maybe solve this in the
future.

Thanks!

Thomas
Thomas De Schampheleire - Sept. 3, 2013, 11:42 a.m.
Hi Thomas, all,

On Tue, Sep 3, 2013 at 9:18 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Tue, 03 Sep 2013 08:16:04 +0200, Arnout Vandecappelle wrote:
>
>> >>   if BR2_LEGACY
>> >>   comment "Your old configuration uses legacy options that no  "
>> >> -comment "longer exist in buildroot.                          "
>> >> -comment "Please look at the options which have been selected "
>> >> -comment "and read their help text.                           "
>> >> -comment "As long as these options stay selected, the build   "
>> >> +comment "longer exist in buildroot, as indicated in the menu "
>> >> +comment "below. As long as these options stay selected, or in"
>> >> +comment "case of string options are non-empty, the build     "
>> >>   comment "will fail.                                          "
>> >> +comment "*                                                   "
>> >> +comment "Where possible, an automatic conversion from old to "
>> >> +comment "new symbols has been performed. Before making any   "
>> >> +comment "change in this legacy menu, make sure to exit the   "
>> >> +comment "configuration editor a first time and save the      "
>> >> +comment "configuration. Otherwise, the automatic conversion  "
>> >> +comment "of symbols will be lost.                            "
>> >
>> > This really seems ugly for users, no? I know it's been discussed, but
>> > can you summarize why this should be done by our users?
>>
>>   I.e., add "because of Kconfig limitations", right?
>
> That I understood, but for my own culture, can you summarize what are
> those limitations? Maybe it would be good to document them in the big
> fat comment inside Config.in.legacy (not the one shown to the user, but
> the one inside the source code). Having to exit menuconfig, and restart
> it doesn't seem like a really great thing, so I'd like to understand
> why we need that, and what are our options to maybe solve this in the
> future.
>

The basic problem is that kconfig seems to remember how a given symbol
was selected, *within one kconfig session*. 'How' can be: explicitly
selected by the user, or selected through a 'select' statement of
another symbol. In the latter case, when the first symbol is disabled,
the 'selected' symbol is also automatically disabled.
When you start a new kconfig session (by saving the configuration and
reopening it) kconfig has no clue anymore about how the different
symbols became selected, because clearly there is no indication about
this whatsoever in the .config file.

Applied to the legacy symbols: suppose symbol FOO is renamed into BAR,
and we have made the legacy symbol FOO 'select' the new symbol BAR
through Config.in.legacy. The user opens the menuconfig, sees that
there is something in the legacy menu, reads the help text, goes to
the menu where FOO used to be selected, sees that BAR is already
correctly selected thanks to the automatic propagation, and decides to
clear the legacy FOO symbol in the legacy menu. Then he saves the
configuration.
If you check the .config file afterwards (or even if you check the BAR
symbol after deselecting FOO before exiting menuconfig) you will see
that BAR is no longer selected. The only way to saveguard that is by
saving the configuration before fiddling with the legacy menu, thereby
'flattening' the symbols.

Provided we want automatic propagation of symbols (boolean or
otherwise), I don't see another solution.
See also the other thread where you asked whether it's at all logical
to have something in legacy for such renames.

Best regards,
Thomas
Thomas Petazzoni - Sept. 3, 2013, 11:52 a.m.
Dear Thomas De Schampheleire,

On Tue, 3 Sep 2013 13:42:39 +0200, Thomas De Schampheleire wrote:

> >> > This really seems ugly for users, no? I know it's been discussed, but
> >> > can you summarize why this should be done by our users?
> >>
> >>   I.e., add "because of Kconfig limitations", right?
> >
> > That I understood, but for my own culture, can you summarize what are
> > those limitations? Maybe it would be good to document them in the big
> > fat comment inside Config.in.legacy (not the one shown to the user, but
> > the one inside the source code). Having to exit menuconfig, and restart
> > it doesn't seem like a really great thing, so I'd like to understand
> > why we need that, and what are our options to maybe solve this in the
> > future.
> >
> 
> The basic problem is that kconfig seems to remember how a given symbol
> was selected, *within one kconfig session*. 'How' can be: explicitly
> selected by the user, or selected through a 'select' statement of
> another symbol. In the latter case, when the first symbol is disabled,
> the 'selected' symbol is also automatically disabled.
> When you start a new kconfig session (by saving the configuration and
> reopening it) kconfig has no clue anymore about how the different
> symbols became selected, because clearly there is no indication about
> this whatsoever in the .config file.
> 
> Applied to the legacy symbols: suppose symbol FOO is renamed into BAR,
> and we have made the legacy symbol FOO 'select' the new symbol BAR
> through Config.in.legacy. The user opens the menuconfig, sees that
> there is something in the legacy menu, reads the help text, goes to
> the menu where FOO used to be selected, sees that BAR is already
> correctly selected thanks to the automatic propagation, and decides to
> clear the legacy FOO symbol in the legacy menu. Then he saves the
> configuration.
> If you check the .config file afterwards (or even if you check the BAR
> symbol after deselecting FOO before exiting menuconfig) you will see
> that BAR is no longer selected. The only way to saveguard that is by
> saving the configuration before fiddling with the legacy menu, thereby
> 'flattening' the symbols.

Thanks for the great summary. I now understand the problem (sorry for
being slow).

> Provided we want automatic propagation of symbols (boolean or
> otherwise), I don't see another solution.
> See also the other thread where you asked whether it's at all logical
> to have something in legacy for such renames.

In the light of this, I indeed restate my question asking whether it's
logical to select BR2_LEGACY for renames that are equivalent.

So I believe I would rather classify the legacy options in two
categories:

 (1) Options that have been renamed, or can be approximated in such a
     close way that letting the user know about the rename or change is
     not important: we simply add an hidden Config.in.legacy symbol that
     selects the new relevant option. This legacy symbol does not select
     BR2_LEGACY, and things are fully transparent for the user. Of
     course the symbol remains =y in the .config file, but it's clearly
     identified as such.

 (2) Options that have been removed, or changed in such a way that it's
     not possible to approximate the modification by selecting other
     options. In this case, the legacy Config.in.legacy symbol is not
     hidden, and only selects BR2_LEGACY and no other option, and the
     user is requested to act by disabling this option and doing the
     necessary configuration changes.

So far, the only problem I see with this are related to minimal
defconfigs. In the case (1) above, the minimal defconfig will continue
to contain the name of the legacy option, and not the name of the new
option, since the new option is selected by the legacy option. This is
annoying since it means minimal defconfigs are not progressively
updated to use the new option name. And this probably makes my entire
proposal moot.

Thomas
Peter Korsgaard - Sept. 3, 2013, 3:06 p.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:


 Thomas> So far, the only problem I see with this are related to minimal
 Thomas> defconfigs. In the case (1) above, the minimal defconfig will continue
 Thomas> to contain the name of the legacy option, and not the name of the new
 Thomas> option, since the new option is selected by the legacy option. This is
 Thomas> annoying since it means minimal defconfigs are not progressively
 Thomas> updated to use the new option name. And this probably makes my entire
 Thomas> proposal moot.

Damn, yes :/

So people really do need to explictly change to the new option / restart
make menuconfig.
Arnout Vandecappelle - Sept. 3, 2013, 4:50 p.m.
On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>
>   Thomas> So far, the only problem I see with this are related to minimal
>   Thomas> defconfigs. In the case (1) above, the minimal defconfig will continue
>   Thomas> to contain the name of the legacy option, and not the name of the new
>   Thomas> option, since the new option is selected by the legacy option. This is
>   Thomas> annoying since it means minimal defconfigs are not progressively
>   Thomas> updated to use the new option name. And this probably makes my entire
>   Thomas> proposal moot.
>
> Damn, yes :/
>
> So people really do need to explictly change to the new option / restart
> make menuconfig.

  I never tried it, but a workaround could be to run olddefconfig before 
any interactive config (menuconfig, nconfig, xconfig, qconfig). 
olddefconfig should be equivalent to saving immediately.

  Regards,
  Arnout
Thomas De Schampheleire - Sept. 4, 2013, 8:33 a.m.
Hi Arnout,

On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>
>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>>>>> writes:
>>
>>
>>
>>   Thomas> So far, the only problem I see with this are related to minimal
>>   Thomas> defconfigs. In the case (1) above, the minimal defconfig will
>> continue
>>   Thomas> to contain the name of the legacy option, and not the name of
>> the new
>>   Thomas> option, since the new option is selected by the legacy option.
>> This is
>>   Thomas> annoying since it means minimal defconfigs are not progressively
>>   Thomas> updated to use the new option name. And this probably makes my
>> entire
>>   Thomas> proposal moot.
>>
>> Damn, yes :/
>>
>> So people really do need to explictly change to the new option / restart
>> make menuconfig.
>
>
>  I never tried it, but a workaround could be to run olddefconfig before any
> interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig
> should be equivalent to saving immediately.

I tried it manually (not yet integrated in a Makefile) and it works as expected.
However, a disadvantage is that any new symbol will no longer be
marked as NEW in the interactive config. So the trade-off would be
between loosing this NEW marker, and requiring the user to do an
intermediate save.

Best regards,
Thomas
Arnout Vandecappelle - Sept. 4, 2013, 4:08 p.m.
On 09/04/13 10:33, Thomas De Schampheleire wrote:
> Hi Arnout,
>
> On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>>
>>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>>>>>> writes:
>>>
>>>
>>>
>>>    Thomas> So far, the only problem I see with this are related to minimal
>>>    Thomas> defconfigs. In the case (1) above, the minimal defconfig will
>>> continue
>>>    Thomas> to contain the name of the legacy option, and not the name of
>>> the new
>>>    Thomas> option, since the new option is selected by the legacy option.
>>> This is
>>>    Thomas> annoying since it means minimal defconfigs are not progressively
>>>    Thomas> updated to use the new option name. And this probably makes my
>>> entire
>>>    Thomas> proposal moot.
>>>
>>> Damn, yes :/
>>>
>>> So people really do need to explictly change to the new option / restart
>>> make menuconfig.
>>
>>
>>   I never tried it, but a workaround could be to run olddefconfig before any
>> interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig
>> should be equivalent to saving immediately.
>
> I tried it manually (not yet integrated in a Makefile) and it works as expected.
> However, a disadvantage is that any new symbol will no longer be
> marked as NEW in the interactive config. So the trade-off would be
> between loosing this NEW marker, and requiring the user to do an
> intermediate save.

  If the user does an intermediate save, the NEW marker will also be gone...

  But at least, this is only for a user that has legacy stuff, not for 
all those innocent people out there that just do a 'make menuconfig' 
after 'git pull'.

  Regards,
  Arnout
Thomas De Schampheleire - Sept. 4, 2013, 7:07 p.m.
Op 4-sep.-2013 20:35 schreef "Arnout Vandecappelle" <arnout@mind.be> het
volgende:
>
> On 09/04/13 10:33, Thomas De Schampheleire wrote:
>>
>> Hi Arnout,
>>
>> On Tue, Sep 3, 2013 at 6:50 PM, Arnout Vandecappelle <arnout@mind.be>
wrote:
>>>
>>> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>>>>>>> writes:
>>>>
>>>>
>>>>
>>>>
>>>>    Thomas> So far, the only problem I see with this are related to
minimal
>>>>    Thomas> defconfigs. In the case (1) above, the minimal defconfig
will
>>>> continue
>>>>    Thomas> to contain the name of the legacy option, and not the name
of
>>>> the new
>>>>    Thomas> option, since the new option is selected by the legacy
option.
>>>> This is
>>>>    Thomas> annoying since it means minimal defconfigs are not
progressively
>>>>    Thomas> updated to use the new option name. And this probably makes
my
>>>> entire
>>>>    Thomas> proposal moot.
>>>>
>>>> Damn, yes :/
>>>>
>>>> So people really do need to explictly change to the new option /
restart
>>>> make menuconfig.
>>>
>>>
>>>
>>>   I never tried it, but a workaround could be to run olddefconfig
before any
>>> interactive config (menuconfig, nconfig, xconfig, qconfig). olddefconfig
>>> should be equivalent to saving immediately.
>>
>>
>> I tried it manually (not yet integrated in a Makefile) and it works as
expected.
>> However, a disadvantage is that any new symbol will no longer be
>> marked as NEW in the interactive config. So the trade-off would be
>> between loosing this NEW marker, and requiring the user to do an
>> intermediate save.
>
>
>  If the user does an intermediate save, the NEW marker will also be
gone...

Yes, but before that save he does see the markers...

>
>  But at least, this is only for a user that has legacy stuff, not for all
those innocent people out there that just do a 'make menuconfig' after 'git
pull'.

Right.

To proceed with this, I think the community should decide which alternative
we prefer, knowing that each one has its pros and cons...

Looking forward to everyone's input...

Best regards,
Thomas

Patch

diff --git a/Config.in.legacy b/Config.in.legacy
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -69,11 +69,27 @@  menu "Legacy config options"
 
 if BR2_LEGACY
 comment "Your old configuration uses legacy options that no  "
-comment "longer exist in buildroot.                          "
-comment "Please look at the options which have been selected "
-comment "and read their help text.                           "
-comment "As long as these options stay selected, the build   "
+comment "longer exist in buildroot, as indicated in the menu "
+comment "below. As long as these options stay selected, or in"
+comment "case of string options are non-empty, the build     "
 comment "will fail.                                          "
+comment "*                                                   "
+comment "Where possible, an automatic conversion from old to "
+comment "new symbols has been performed. Before making any   "
+comment "change in this legacy menu, make sure to exit the   "
+comment "configuration editor a first time and save the      "
+comment "configuration. Otherwise, the automatic conversion  "
+comment "of symbols will be lost.                            "
+comment "*                                                   "
+comment "After this initial save, reopen the configuration   "
+comment "editor, inspect the options selected below, read    "
+comment "their help texts, and verify/update the new         "
+comment "configuration in the corresponding configuration    "
+comment "menus. When everything is ok, you can disable the   "
+comment "legacy options in the menu below. Once you have     "
+comment "disabled all legacy options, this text will         "
+comment "disappear and you will be able to start the build.  "
+comment "*                                                   "
 comment "Note: at some point in the future, the oldest legacy"
 comment "options will be removed, and configuration files    "
 comment "that still have those options set, will fail to     "