[Buildroot] [PATCH 2 of 9 v4] Config.in.legacy: update description for users

[Thomas De Schampheleire]

Op 4-sep.-2013 20:35 schreef "Arnout Vandecappelle" <arnout at 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 at mind.be>
wrote:
>>>
>>> On 09/03/13 17:06, Peter Korsgaard wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130904/5990fb74/attachment-0002.html>