| Message ID | ac4d080274a06689e8d4.1378152471@argentina |
|---|---|
| State | Accepted |
| Commit | cce5baa8ee8eb9bbe27448aa75b67719431bf9e9 |
| Headers | show |
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
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
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
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
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
>>>>> "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.
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
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
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
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
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 "
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(-)