Patchwork [v2,1/3] barebox: add custom version option

login
register
mail settings
Submitter Fabio Porcedda
Date April 17, 2013, 7:41 a.m.
Message ID <1366184503-16875-2-git-send-email-fabio.porcedda@gmail.com>
Download mbox | patch
Permalink /patch/237158/
State Superseded
Headers show

Comments

Fabio Porcedda - April 17, 2013, 7:41 a.m.
Add custom version option as used in the linux kernel.
This way we can easily specify newer and older version.
Remove the list of the older versions because is obsoleted
by the new custom version option that is more flexible.

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 boot/barebox/Config.in | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)
Thomas Petazzoni - May 1, 2013, 9:10 p.m.
Dear Fabio Porcedda,

On Wed, 17 Apr 2013 09:41:41 +0200, Fabio Porcedda wrote:

> -config BR2_TARGET_BAREBOX_2013_01
> -	bool "2013.01.0"
> -
> -config BR2_TARGET_BAREBOX_2013_02
> -	bool "2013.02.0"
> -
> -config BR2_TARGET_BAREBOX_2013_03
> -	bool "2013.03.0"
> -
> -config BR2_TARGET_BAREBOX_2013_04
> +config BR2_TARGET_BAREBOX_LATEST_VERSION
>  	bool "2013.04.0"
>  
> +config BR2_TARGET_BAREBOX_CUSTOM_VERSION
> +	bool "Custom version"
> +	help
> +	  This option allows to use a specific official versions
> +

We need to have something that is consistent between U-Boot, Barebox
and the kernel. Currently U-Boot has a version selection, the Linux
kernel allows to chose the latest version (but with an option named
after the version itself, so the name of the option changes when the
version changes) or a custom version, and now for Barebox you're
proposing yet another solution: select the latest version (with an
option name that never changes) or a custom version.

So, I'm fine doing changes on this, but they should be consistent
across packages.

Best regards,

Thomas
Fabio Porcedda - May 3, 2013, 6:49 a.m.
On Wed, May 1, 2013 at 11:10 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Fabio Porcedda,

Hi Thomas,
thanks for reviewing.

> On Wed, 17 Apr 2013 09:41:41 +0200, Fabio Porcedda wrote:
>
>> -config BR2_TARGET_BAREBOX_2013_01
>> -     bool "2013.01.0"
>> -
>> -config BR2_TARGET_BAREBOX_2013_02
>> -     bool "2013.02.0"
>> -
>> -config BR2_TARGET_BAREBOX_2013_03
>> -     bool "2013.03.0"
>> -
>> -config BR2_TARGET_BAREBOX_2013_04
>> +config BR2_TARGET_BAREBOX_LATEST_VERSION
>>       bool "2013.04.0"
>>
>> +config BR2_TARGET_BAREBOX_CUSTOM_VERSION
>> +     bool "Custom version"
>> +     help
>> +       This option allows to use a specific official versions
>> +
>
> We need to have something that is consistent between U-Boot, Barebox
> and the kernel. Currently U-Boot has a version selection, the Linux
> kernel allows to chose the latest version (but with an option named
> after the version itself, so the name of the option changes when the
> version changes) or a custom version, and now for Barebox you're
> proposing yet another solution: select the latest version (with an
> option name that never changes) or a custom version.

I think it's easier to have a option name that doesn't change.
If there isn't a specific reason to have a option name that changes then
I will send a patch to change the linux kernel option name.

BR2_LINUX_KERNEL_3_9 -> BR2_LINUX_KERNEL_LATEST_VERSION

Best regards
Fabio Porcedda

>
> So, I'm fine doing changes on this, but they should be consistent
> across packages.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com



--
Fabio Porcedda
Fabio Porcedda - May 3, 2013, 7:57 a.m.
On Fri, May 3, 2013 at 8:49 AM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote:
> On Wed, May 1, 2013 at 11:10 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear Fabio Porcedda,
>
> Hi Thomas,
> thanks for reviewing.
>
>> On Wed, 17 Apr 2013 09:41:41 +0200, Fabio Porcedda wrote:
>>
>>> -config BR2_TARGET_BAREBOX_2013_01
>>> -     bool "2013.01.0"
>>> -
>>> -config BR2_TARGET_BAREBOX_2013_02
>>> -     bool "2013.02.0"
>>> -
>>> -config BR2_TARGET_BAREBOX_2013_03
>>> -     bool "2013.03.0"
>>> -
>>> -config BR2_TARGET_BAREBOX_2013_04
>>> +config BR2_TARGET_BAREBOX_LATEST_VERSION
>>>       bool "2013.04.0"
>>>
>>> +config BR2_TARGET_BAREBOX_CUSTOM_VERSION
>>> +     bool "Custom version"
>>> +     help
>>> +       This option allows to use a specific official versions
>>> +
>>
>> We need to have something that is consistent between U-Boot, Barebox
>> and the kernel. Currently U-Boot has a version selection, the Linux
>> kernel allows to chose the latest version (but with an option named
>> after the version itself, so the name of the option changes when the
>> version changes) or a custom version, and now for Barebox you're
>> proposing yet another solution: select the latest version (with an
>> option name that never changes) or a custom version.
>
> I think it's easier to have a option name that doesn't change.
> If there isn't a specific reason to have a option name that changes then
> I will send a patch to change the linux kernel option name.
>
> BR2_LINUX_KERNEL_3_9 -> BR2_LINUX_KERNEL_LATEST_VERSION

In the toolchain/kernel-headers/Config.in
there are many BR2_KERNEL_HEADERS_3_X options,
for headers is impossible to change the option names and use only one.

So I must use BR2_TARGET_BAREBOX_2013_04 for barebox?

Best regards
Fabio Porcedda

> Best regards
> Fabio Porcedda
>
>>
>> So, I'm fine doing changes on this, but they should be consistent
>> across packages.
>>
>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
>
>
>
> --
> Fabio Porcedda



--
Fabio Porcedda
Thomas Petazzoni - May 3, 2013, 8:55 a.m.
Dear Fabio Porcedda,

On Fri, 3 May 2013 08:49:04 +0200, Fabio Porcedda wrote:

> > On Wed, 17 Apr 2013 09:41:41 +0200, Fabio Porcedda wrote:
> >
> >> -config BR2_TARGET_BAREBOX_2013_01
> >> -     bool "2013.01.0"
> >> -
> >> -config BR2_TARGET_BAREBOX_2013_02
> >> -     bool "2013.02.0"
> >> -
> >> -config BR2_TARGET_BAREBOX_2013_03
> >> -     bool "2013.03.0"
> >> -
> >> -config BR2_TARGET_BAREBOX_2013_04
> >> +config BR2_TARGET_BAREBOX_LATEST_VERSION
> >>       bool "2013.04.0"
> >>
> >> +config BR2_TARGET_BAREBOX_CUSTOM_VERSION
> >> +     bool "Custom version"
> >> +     help
> >> +       This option allows to use a specific official versions
> >> +
> >
> > We need to have something that is consistent between U-Boot, Barebox
> > and the kernel. Currently U-Boot has a version selection, the Linux
> > kernel allows to chose the latest version (but with an option named
> > after the version itself, so the name of the option changes when the
> > version changes) or a custom version, and now for Barebox you're
> > proposing yet another solution: select the latest version (with an
> > option name that never changes) or a custom version.
> 
> I think it's easier to have a option name that doesn't change.
> If there isn't a specific reason to have a option name that changes
> then I will send a patch to change the linux kernel option name.
> 
> BR2_LINUX_KERNEL_3_9 -> BR2_LINUX_KERNEL_LATEST_VERSION

I don't really have a strong opinion about this thing, probably Peter
and Arnout have more ideas than I do on this.

The only thing I care about is to not make modifications specifically
on Barebox that are inconsistent with what is done on U-Boot, the
kernel, or other version-selectable components. For example, U-Boot
still allows to chose between several recent versions, which would make
it inconsistent with the patches you're proposing, and that's the thing
I don't like.

Best regards,

Thomas
Fabio Porcedda - May 3, 2013, 9:17 a.m.
On Fri, May 3, 2013 at 10:55 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Fabio Porcedda,
>
> On Fri, 3 May 2013 08:49:04 +0200, Fabio Porcedda wrote:
>
>> > On Wed, 17 Apr 2013 09:41:41 +0200, Fabio Porcedda wrote:
>> >
>> >> -config BR2_TARGET_BAREBOX_2013_01
>> >> -     bool "2013.01.0"
>> >> -
>> >> -config BR2_TARGET_BAREBOX_2013_02
>> >> -     bool "2013.02.0"
>> >> -
>> >> -config BR2_TARGET_BAREBOX_2013_03
>> >> -     bool "2013.03.0"
>> >> -
>> >> -config BR2_TARGET_BAREBOX_2013_04
>> >> +config BR2_TARGET_BAREBOX_LATEST_VERSION
>> >>       bool "2013.04.0"
>> >>
>> >> +config BR2_TARGET_BAREBOX_CUSTOM_VERSION
>> >> +     bool "Custom version"
>> >> +     help
>> >> +       This option allows to use a specific official versions
>> >> +
>> >
>> > We need to have something that is consistent between U-Boot, Barebox
>> > and the kernel. Currently U-Boot has a version selection, the Linux
>> > kernel allows to chose the latest version (but with an option named
>> > after the version itself, so the name of the option changes when the
>> > version changes) or a custom version, and now for Barebox you're
>> > proposing yet another solution: select the latest version (with an
>> > option name that never changes) or a custom version.
>>
>> I think it's easier to have a option name that doesn't change.
>> If there isn't a specific reason to have a option name that changes
>> then I will send a patch to change the linux kernel option name.
>>
>> BR2_LINUX_KERNEL_3_9 -> BR2_LINUX_KERNEL_LATEST_VERSION
>
> I don't really have a strong opinion about this thing, probably Peter
> and Arnout have more ideas than I do on this.
>
> The only thing I care about is to not make modifications specifically
> on Barebox that are inconsistent with what is done on U-Boot, the
> kernel, or other version-selectable components. For example, U-Boot
> still allows to chose between several recent versions, which would make
> it inconsistent with the patches you're proposing, and that's the thing
> I don't like.

In the patch set v3 barebox is consistent with the kernel.

If you are speaking just about consistency, I can send a patch for U-Boot too.
IMHO the kernel way is more flexible, so if we must choose only one method,
the kernel way is better.

A problem with having only the latest three version available
is that barebox and u-boot release frequency are very different.
Barebox have 12 release per year, U-Boot only 4.
The latest three release of U-Boot cover nine months but the latest
three release of barebox cover only three months.
So if a defconfig use a specific barebox version, that defconfig can
be used only for three months.
I think that three months is not enough.

It's better if i send patch for U-Boot too?

Best regards
Fabio Porcedda

> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

--
Fabio Porcedda
Thomas Petazzoni - May 3, 2013, 10:11 a.m.
Dear Fabio Porcedda,

On Fri, 3 May 2013 11:17:32 +0200, Fabio Porcedda wrote:

> In the patch set v3 barebox is consistent with the kernel.
> 
> If you are speaking just about consistency, I can send a patch for
> U-Boot too. IMHO the kernel way is more flexible, so if we must
> choose only one method, the kernel way is better.
> 
> A problem with having only the latest three version available
> is that barebox and u-boot release frequency are very different.
> Barebox have 12 release per year, U-Boot only 4.
> The latest three release of U-Boot cover nine months but the latest
> three release of barebox cover only three months.
> So if a defconfig use a specific barebox version, that defconfig can
> be used only for three months.
> I think that three months is not enough.

I think what you say makes sense.

> It's better if i send patch for U-Boot too?

Yes. I would however maybe wait for the opinion of others like Arnout,
Peter or Gustavo. Maybe they disagree with my opinion, and I don't want
you to do extra work that may not be accepted in the end.

Best regards,

Thomas
Peter Korsgaard - May 3, 2013, 10:50 a.m.
>>>>> "Fabio" == Fabio Porcedda <fabio.porcedda@gmail.com> writes:

Hi,

 Fabio> I think it's easier to have a option name that doesn't change.
 Fabio> If there isn't a specific reason to have a option name that
 Fabio> changes then I will send a patch to change the linux kernel
 Fabio> option name.

 Fabio> BR2_LINUX_KERNEL_3_9 -> BR2_LINUX_KERNEL_LATEST_VERSION

Agreed. With the _3_9 option people often don't realize that it will
only exist for a few months, and that they should use the CUSTOM_VERSION
stuff to really fix the version.
Fabio Porcedda - May 3, 2013, 11:26 a.m.
On Fri, May 3, 2013 at 12:50 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Fabio" == Fabio Porcedda <fabio.porcedda@gmail.com> writes:
>
> Hi,
>
>  Fabio> I think it's easier to have a option name that doesn't change.
>  Fabio> If there isn't a specific reason to have a option name that
>  Fabio> changes then I will send a patch to change the linux kernel
>  Fabio> option name.
>
>  Fabio> BR2_LINUX_KERNEL_3_9 -> BR2_LINUX_KERNEL_LATEST_VERSION
>
> Agreed. With the _3_9 option people often don't realize that it will
> only exist for a few months, and that they should use the CUSTOM_VERSION
> stuff to really fix the version.
>
> --
> Bye, Peter Korsgaard

Ok good, I will send a v4 adding that patch.

Best regards
--
Fabio Porcedda
Arnout Vandecappelle - May 3, 2013, 4:46 p.m.
On 03/05/13 11:17, Fabio Porcedda wrote:
> On Fri, May 3, 2013 at 10:55 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
[snip]
>> I don't really have a strong opinion about this thing, probably Peter
>> and Arnout have more ideas than I do on this.

  I don't. I started to reply this morning, then realized that I couldn't 
formulate it consistently, so I gave up.

  The _LATEST symbol name has the disadvantage that your build is not 
reproducible when you update buildroot, because the meaning of "latest" 
will have changed. However, this is already the case for all other 
packages (which don't allow choosing the version).

  With the version number in the symbol name, at least you are warned by 
make oldconfig when the version has changed, because it will offer the 
choice again.

  That said, I find this disadvantage so minor that it is not worth the 
effort of changing the symbol name all the time. So either option is fine 
for me.


>> The only thing I care about is to not make modifications specifically
>> on Barebox that are inconsistent with what is done on U-Boot, the
>> kernel, or other version-selectable components. For example, U-Boot
>> still allows to chose between several recent versions, which would make
>> it inconsistent with the patches you're proposing, and that's the thing
>> I don't like.
>
> In the patch set v3 barebox is consistent with the kernel.
>
> If you are speaking just about consistency, I can send a patch for U-Boot too.
> IMHO the kernel way is more flexible, so if we must choose only one method,
> the kernel way is better.
>
> A problem with having only the latest three version available
> is that barebox and u-boot release frequency are very different.
> Barebox have 12 release per year, U-Boot only 4.
> The latest three release of U-Boot cover nine months but the latest
> three release of barebox cover only three months.
> So if a defconfig use a specific barebox version, that defconfig can
> be used only for three months.
> I think that three months is not enough.

  I agree with that one.  In fact, I don't think it makes much sense to 
have the option to go for an earlier version, also for U-Boot. If you 
need an earlier version (e.g. because you have patches that won't apply 
to the current version), chances are that it is not one of the few that 
are offered by buildroot. BTW, a nice addition would be to require 
_CUSTOM_VERSION before you can specify a patch directory, so that this 
consistency is guaranteed to some extent.

  So I think that Fabio's basic approach (offer only the latest version, 
but also have the option to specify the version) is the best one.

> It's better if i send patch for U-Boot too?

  I would say yes, that would be nice.


  But let's hear what Peter has to say as well.

  Regards,
  Arnout
Peter Korsgaard - May 6, 2013, 2:15 p.m.
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> It's better if i send patch for U-Boot too?

 Arnout>  I would say yes, that would be nice.

 Arnout>  But let's hear what Peter has to say as well.

I agree completely. _LATEST + custom version makes sense.

Patch

diff --git a/boot/barebox/Config.in b/boot/barebox/Config.in
index 581cc52..af97be7 100644
--- a/boot/barebox/Config.in
+++ b/boot/barebox/Config.in
@@ -12,18 +12,14 @@  choice
 	help
 	  Select the specific Barebox version you want to use
 
-config BR2_TARGET_BAREBOX_2013_01
-	bool "2013.01.0"
-
-config BR2_TARGET_BAREBOX_2013_02
-	bool "2013.02.0"
-
-config BR2_TARGET_BAREBOX_2013_03
-	bool "2013.03.0"
-
-config BR2_TARGET_BAREBOX_2013_04
+config BR2_TARGET_BAREBOX_LATEST_VERSION
 	bool "2013.04.0"
 
+config BR2_TARGET_BAREBOX_CUSTOM_VERSION
+	bool "Custom version"
+	help
+	  This option allows to use a specific official versions
+
 config BR2_TARGET_BAREBOX_CUSTOM_TARBALL
 	bool "Custom tarball"
 
@@ -32,6 +28,10 @@  config BR2_TARGET_BAREBOX_CUSTOM_GIT
 
 endchoice
 
+config BR2_TARGET_BAREBOX_CUSTOM_VERSION_VALUE
+	string "Barebox version"
+	depends on BR2_TARGET_BAREBOX_CUSTOM_VERSION
+
 if BR2_TARGET_BAREBOX_CUSTOM_TARBALL
 
 config BR2_TARGET_BAREBOX_CUSTOM_TARBALL_LOCATION
@@ -41,10 +41,8 @@  endif
 
 config BR2_TARGET_BAREBOX_VERSION
 	string
-	default "2013.01.0"	if BR2_TARGET_BAREBOX_2013_01
-	default "2013.02.0"	if BR2_TARGET_BAREBOX_2013_02
-	default "2013.03.0"	if BR2_TARGET_BAREBOX_2013_03
-	default "2013.04.0"	if BR2_TARGET_BAREBOX_2013_04
+	default "2013.04.0"	if BR2_TARGET_BAREBOX_LATEST_VERSION
+	default $BR2_TARGET_BAREBOX_CUSTOM_VERSION_VALUE if BR2_TARGET_BAREBOX_CUSTOM_VERSION
 	default "custom"	if BR2_TARGET_BAREBOX_CUSTOM_TARBALL
 	default $BR2_TARGET_BAREBOX_CUSTOM_GIT_VERSION if BR2_TARGET_BAREBOX_CUSTOM_GIT