[oe] [STABLE] branch created: stable/2009

[Esben Haabendal]

On Thu, Apr 2, 2009 at 1:25 PM, Marcin Juszkiewicz
<marcin at juszkiewicz.com.pl> wrote:
> Dnia czwartek, 2 kwietnia 2009 o 12:52:51 Esben Haabendal napisał(a):
>> On Tue, Mar 31, 2009 at 6:37 PM, Marcin Juszkiewicz
>>
>> <marcin at juszkiewicz.com.pl> wrote:
>> > I also imported BitBake 1.8.12 (last release) into "stable/2009"
>> > branch as this is minimal stable version which works with this
>> > repository.
>>
>> Is this the new strategy for handling depedency on specific versions
>> of BitBake?
>
> No, but we require minimal versions of BitBake to be used with OE
> metadata so I prefer to have version which is granted to work. Imagine
> situation when OE.dev will require BitBake 1.8.22 which will not work
> with 'stable/2009' branch.

I fully understand the situation, but I am just wondering if we shouldn't be
paying more attention to this problem.

For the stable branches I need to maintain, I have had to make a solution
control which version of bitbake is used with each branch. Maybe it would
be worth to try work out a more general version of such a solutin.

But, I think it would be great if we "encode" into the OpenEmbedded
metadata which version of bitbake is recommended, and maybe even
which versions work and which is not expected to work. It could be
something as simple as adding a ".bitbake" to the top of the
metadata which contains a single line in the style of
"tags/bitbake-1.8.10", which would then make it possible for
people to know which version to use, and even automate
this in their setups.

We could then also make bitbake aware of this file, and then print
out a warning if a "wrong" version is used.

I am sure I am not the only one who have had to debug strange
problems before finding out that it would just be easier to go back
to an older bitbake version...

It is not that it is a big problem to import BitBake into OpenEmbedded,
although it generally is not the best solution to many things, as it
makes it a bit painful to propagate eventual critical fixes to all
the places where it is needed, but I just think that this is an
important issue that is worth to find a proper solution for.

Regards,
-- 
Esben Haabendal, Senior Software Consultant
DoréDevelopment ApS, Ved Stranden 1, 9560 Hadsund, DK-Denmark
Phone: +45 51 92 53 93, E-mail: eha at doredevelopment.dk
WWW: http://www.doredevelopment.dk