[Buildroot] Suggestion, Keep version in a separate file.

[Buildroot] Suggestion, Keep version in a separate file.

[Ulf Samuelsson]

I believe it would be a good
idea to separate the version
info and download site 
from the <package>.mk.
and keep a central file
with this info.

This would make it easier
to handle several projects
using different versions
of packages with the same
framework.
As part of this I think patches
to packages should reside
in a subdirectory to the
main package directory.

/Ulf

[Buildroot] Suggestion, Keep version in a separate file.

[Marc Lindahl]

That sounds like it would make the buildroot system overly complicated 
for an rare edge case.
You can do that by managing your .config files - many ways to do that 
already....

On Nov 6, 2006, at 3:29 PM, Ulf Samuelsson wrote:

>
> I believe it would be a good
> idea to separate the version
> info and download site
> from the <package>.mk.
> and keep a central file
> with this info.
>
> This would make it easier
> to handle several projects
> using different versions
> of packages with the same
> framework.
> As part of this I think patches
> to packages should reside
> in a subdirectory to the
> main package directory.
>
> /Ulf
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Suggestion, Keep version in a separate file.

[Nathanael D. Noblet]

On Mon, 2006-11-06 at 22:29 +0200, Ulf Samuelsson wrote:
> I believe it would be a good
> idea to separate the version
> info and download site 
> from the <package>.mk.
> and keep a central file
> with this info.
> 
> This would make it easier
> to handle several projects
> using different versions
> of packages with the same
> framework.
> As part of this I think patches
> to packages should reside
> in a subdirectory to the
> main package directory.

Though I don't know if the implementation idea is the same, I would
*love* a system that allows me to build multiple root fs, and keep the
versions of all packages etc. so that I can reproduce it at will and/or
upgrade a package version for only one target. I started working on
something similar to what you are suggesting, but then my RAID 5 array
had 1 drive die, and bad blocks on the second grrrr so I've lost all
that I had done. I would be interested in helping. I think the main
point to success for something like this is that without any work on
everyone elses part buildroot needs to continue to function as it does
now for the most part, but those of us that want to be able to use it as
you describe could, without much difficulty.
-- 
Nathanael D. Noblet <nathanael@gnat.ca>
Gnat Solutions, Inc

[Buildroot] Suggestion, Keep version in a separate file.

[Ulf Samuelsson]

 
That sounds like it would make the buildroot system overly complicated 
for an rare edge case.
You can do that by managing your .config files - many ways to do that 
already....

=> I really do not see
    how I can, using .config,
    select between 
    package-1.18 and
    package-1.19 unless
    there is support for
    it in the Config.in files.
    (Which there isn't)
    so I have to use two
    different versions of
    buildroot and this is
    making life more 
    complex.

    Anyway, what's so complex
    about adding an extra
    include statement in
    the Makefile?
    
    include $(BR2_VERSION_INFO)

    and set this to ".versions"
    in the main Config.in as
    default.
    If a user wants a different
    set of package versions
    then it is easy to select
    another file.

    By using different .config
    files you easily can maintain different projects using different Version Info files.


    I doubt this is a corner
    case.  Anyone that is supporting more than one
project runs into this problem.



On Nov 6, 2006, at 3:29 PM, Ulf Samuelsson wrote:

>
> I believe it would be a good
> idea to separate the version
> info and download site
> from the <package>.mk.
> and keep a central file
> with this info.
>
> This would make it easier
> to handle several projects
> using different versions
> of packages with the same
> framework.
> As part of this I think patches
> to packages should reside
> in a subdirectory to the
> main package directory.
>
> /Ulf
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Suggestion, Keep version in a separate file.

[Marc Lindahl]

On Nov 7, 2006, at 2:43 AM, Ulf Samuelsson wrote:

>
> That sounds like it would make the buildroot system overly complicated
> for an rare edge case.
> You can do that by managing your .config files - many ways to do that
> already....
>
> => I really do not see
>     how I can, using .config,
>     select between
>     package-1.18 and
>     package-1.19 unless
>     there is support for
>     it in the Config.in files.
>     (Which there isn't)
>     so I have to use two
>     different versions of
>     buildroot and this is
>     making life more
>     complex.
>
>     Anyway, what's so complex
>     about adding an extra
>     include statement in
>     the Makefile?
>
>     include $(BR2_VERSION_INFO)

one more thing that could cause serious confusion in the normal case...


>
>     and set this to ".versions"
>     in the main Config.in as
>     default.
>     If a user wants a different
>     set of package versions
>     then it is easy to select
>     another file.
>
>     By using different .config
>     files you easily can maintain different projects using different 
> Version Info files.
>
>
>     I doubt this is a corner
>     case.  Anyone that is supporting more than one
> project runs into this problem.


I disagree that to manage separate projects within the same buildroot 
tree makes any sense whatsoever.  It opens the opportunity that 
unrelated projects could intermingle - cross-pollinating bugs, etc.

I really for the life of me can't figure out why you'd want to do that 
- normally you want a bunch of builds all using the same packages (e.g. 
debugging, emulator, eval board, target hardware, etc.) - in which case 
you really want to be sure that your packages are all the same, else 
you debug a different version than you release!

perhaps you can give a real-world example or two?

buildroot already supports the speed optimization to relocate the 
package directory... you could have all your projects pointing to the 
same one without the intermingling problem.

for separate projects why wouldn't you have separate buildroot trees - 
I know I would for no other reason than the usual contractual 
non-disclosures that come with consulting jobs.

[Buildroot] Suggestion, Keep version in a separate file.

[Ulf Samuelsson]

Marc Lindahl skrev:
> On Nov 7, 2006, at 2:43 AM, Ulf Samuelsson wrote:
> 
>> That sounds like it would make the buildroot system overly complicated
>> for an rare edge case.
>> You can do that by managing your .config files - many ways to do that
>> already....
>>
>> => I really do not see
>>     how I can, using .config,
>>     select between
>>     package-1.18 and
>>     package-1.19 unless
>>     there is support for
>>     it in the Config.in files.
>>     (Which there isn't)
>>     so I have to use two
>>     different versions of
>>     buildroot and this is
>>     making life more
>>     complex.
>>
>>     Anyway, what's so complex
>>     about adding an extra
>>     include statement in
>>     the Makefile?
>>
>>     include $(BR2_VERSION_INFO)
> 
> one more thing that could cause serious confusion in the normal case...

Why is this confusing?
BR2_VERSION_INFO is set to ".version" as default.

> 
> 
>>     and set this to ".versions"
>>     in the main Config.in as
>>     default.
>>     If a user wants a different
>>     set of package versions
>>     then it is easy to select
>>     another file.
>>
>>     By using different .config
>>     files you easily can maintain different projects using different 
>> Version Info files.
>>
>>
>>     I doubt this is a corner
>>     case.  Anyone that is supporting more than one
>> project runs into this problem.
> 
> 
> I disagree that to manage separate projects within the same buildroot 
> tree makes any sense whatsoever.  It opens the opportunity that 
> unrelated projects could intermingle - cross-pollinating bugs, etc.

The goal is to have a single source for the buildroot, and
to allow the complete customer project to be deleted, with the exception
of the .config and the .version file.
It shall handle several versions for each customer and several customers
using this single source tree with minimal effort.

The current buildroot structure does not support this so
you have to have multiple buildroot tarballs and have to remember
which is used for which customer.

> I really for the life of me can't figure out why you'd want to do that 
> - normally you want a bunch of builds all using the same packages (e.g. 
> debugging, emulator, eval board, target hardware, etc.) - in which case 
> you really want to be sure that your packages are all the same, else 
> you debug a different version than you release!
> 
> perhaps you can give a real-world example or two?
> 
Customer A pays for a distribution, and the combination of packages is
thoroughly tested.
Customer B pays for a distribution one year later and a different
combination of packages is tested.
Customer A comes back and wants to have a new package added to his/her
distribution, but does not want to retest the rest.
Customer B comes back and wants to have a bugfix of <package>-1.18
This bugfix exists in <package>-1.22.

With the proposal, you can keep a single source code for buildroot
and just add a .config file and a .version file and you can reproduce
everything you did the last time.
For customer A, you edit the .version file <.version-customer-A-1.0>
to ensure that you have the desired version of the new package and
store in <.version-customer-A-1.1>. A new -.config file is generated to
include the new version file as well as the old.

For customer B, you edit the <.version-customer-B-1.0> file
to use <package>-1.22 and this is stored in <.version-customer-B-1.1>.
All new packages are built in build_<arch>_customer_B_V1.1

Everything can be maintained using a single source package.


> buildroot already supports the speed optimization to relocate the 
> package directory... you could have all your projects pointing to the 
> same one without the intermingling problem.
> 
> for separate projects why wouldn't you have separate buildroot trees - 
> I know I would for no other reason than the usual contractual 
> non-disclosures that come with consulting jobs.

You do not have to store the .config and .version files inside the
source package.
Also if there are customer specific packages, they can probably be
applied using a new directory "local" (similar to packages) which is
customer specific and stored outside the normal source package.


> 
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 297 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20061107/25459d86/attachment.vcf 

[Buildroot] Suggestion, Keep version in a separate file.

[Marc Lindahl]

On Nov 7, 2006, at 4:10 PM, Ulf Samuelsson wrote:

> Marc Lindahl skrev:
>>
>> one more thing that could cause serious confusion in the normal 
>> case...
>
> Why is this confusing?
> BR2_VERSION_INFO is set to ".version" as default.

When something goes wrong, it's a subtle change that can cause havoc, 
supporting only this odd corner case.  (e.g. what if it's missing and 
shouldn't be, what if it's slightly mis-named, etc. etc.)

>> I disagree that to manage separate projects within the same buildroot
>> tree makes any sense whatsoever.  It opens the opportunity that
>> unrelated projects could intermingle - cross-pollinating bugs, etc.
>
> The goal is to have a single source for the buildroot,

For every project you do?  I disagree with that as a useful goal.

>  and
> to allow the complete customer project to be deleted, with the 
> exception
> of the .config and the .version file.
> It shall handle several versions for each customer and several 
> customers
> using this single source tree with minimal effort.

Sounds confusing already.

>
> The current buildroot structure does not support this so
> you have to have multiple buildroot tarballs and have to remember
> which is used for which customer.

How is that hard?  If you can't remember the customer...
In any case typically there is more than buildroot for a project, 
there's hardware, tons of other odds and ends... it's likely there's a 
whole directory structure for each customer.


>
>> I really for the life of me can't figure out why you'd want to do that
>> - normally you want a bunch of builds all using the same packages 
>> (e.g.
>> debugging, emulator, eval board, target hardware, etc.) - in which 
>> case
>> you really want to be sure that your packages are all the same, else
>> you debug a different version than you release!
>>
>> perhaps you can give a real-world example or two?
>>
> Customer A pays for a distribution, and the combination of packages is
> thoroughly tested.
> Customer B pays for a distribution one year later and a different
> combination of packages is tested.
> Customer A comes back and wants to have a new package added to his/her
> distribution, but does not want to retest the rest.

Changing a package without restesting the release??

> Customer B comes back and wants to have a bugfix of <package>-1.18
> This bugfix exists in <package>-1.22.
>
> With the proposal, you can keep a single source code for buildroot
> and just add a .config file and a .version file and you can reproduce
> everything you did the last time.
> For customer A, you edit the .version file <.version-customer-A-1.0>
> to ensure that you have the desired version of the new package and
> store in <.version-customer-A-1.1>. A new -.config file is generated to
> include the new version file as well as the old.
>
> For customer B, you edit the <.version-customer-B-1.0> file
> to use <package>-1.22 and this is stored in <.version-customer-B-1.1>.
> All new packages are built in build_<arch>_customer_B_V1.1
>
> Everything can be maintained using a single source package.

This whole scenario mixes together customer A and B, which is 
customarily a bad idea, both in practice, and usually prohibited by 
NDAs and the like.

No benefit in organization or storage...

Also no consideration was made for CVS or other version control - each 
customer has a separate repository.


>
>
>> buildroot already supports the speed optimization to relocate the
>> package directory... you could have all your projects pointing to the
>> same one without the intermingling problem.
>>
>> for separate projects why wouldn't you have separate buildroot trees -
>> I know I would for no other reason than the usual contractual
>> non-disclosures that come with consulting jobs.
>
> You do not have to store the .config and .version files inside the
> source package.
> Also if there are customer specific packages, they can probably be
> applied using a new directory "local" (similar to packages) which is
> customer specific and stored outside the normal source package.
>

So now you have one combined tree for all your customers - except you 
have separate trees elsewhere to hold separate .config and .version 
files?

Well, you made my case for me!

M


>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at uclibc.org
>> http://busybox.net/mailman/listinfo/buildroot
>
> <ulf.vcf>