[Buildroot] [PATCH 3 of 6 v2] linux: add support for custom Mercurial repository

[Arnout Vandecappelle]

On 08/20/13 10:36, Thomas De Schampheleire wrote:
> To come back on the question: should we try and propagate the options
> from old to new string options or not.
> The original patch did not do that, the user was responsible for
> making the change.
> Arnout responded that he'd like to make it 'just work' for the user,
> and advocated automatic propagation.
> I originally agreed to this reasoning, but am now reconsidering.
> To implement the automatic propagation of string values, we'd have:
>
> config FOO_NEW_STRING (in linux/Config.in)
>          default FOO_OLD_STRING if FOO_OLD_STRING != ""
>
> config FOO_OLD_STRING (in Config.in.legacy)
>
> However, the behavior of this combination is odd: if you start from an
> old config, update to the newer buildroot, and run make menuconfig,
> you get the legacy warnings (as expected). In the Kernel menu, the new
> strings are correctly showing the original values (this is the
> automatic propagation). In the Legacy menu, the original values are
> shown too. Everything seems fine up to this point, but there are two
> scenarios now:
> 1. to clear the legacy messages, you have to empty the original string
> in the legacy menu. If you do that, however, the new string in the
> Kernel menu will also be cleared! If you now save your config, the
> original string is gone everywhere.
> 2. if you first save the config (legacy warnings still intact), then
> reopen menuconfig and clear the legacy warnings, the automatic
> propagation holds, and now the Kernel menu still contains the original
> values.
 >
 > This behavior is very confusing and annoying, IMO. A typical user
 > would perform scenario 1, not knowing about the mentioned problem.


  I agree that it is confusing and annoying. However, this is the same 
behaviour as for boolean options. So if we accept this argument, then 
also the automatic propagation for boolean options should be removed.

  So maybe we could make the options with automatic propagation not 
select BR2_LEGACY. If it is indeed just a symbol rename, then the user 
doesn't need to be made aware of it, I guess. The disadvantage is that 
the old options will still appear in saved defconfigs, but that's a minor 
thing according to me.

  Another option is warn the user in the comments at the top of 
Config.in.legacy that they should save and re-run menuconfig.



> An additional advantage of not automatic propagating, is that there is
> just one place that deals with legacy options: Config.in.legacy. To
> remove support for all legacy options, we could just delete that one
> file and be done with it. However, to automatically propagate string
> options, we also have to change additional files (linux/Config.in in
> this example), which is less clean.

  But I don't think that's a big deal. Config.in.legacy can contain some 
text to point to the other place where the symbol has to be removed.


> Both arguments lead me to advocating not automatically propagating
> legacy string options.

  If that is the case, then simple renames of config symbols should still 
be avoided, I think. We want it to be really easy for people to upgrade 
buildroot, so they shouldn't be exposed to the whole legacy stuff unless 
really needed.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F