Migrate, or not Migrate, that's the question!!!

Migrate, or not Migrate, that's the question!!!

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 1699 bytes --]

Hello folks,


I'm in a project that uses openembedded-classic and Arago stuff to build
the product's image.
A lot of problems have been raised in relation to build time, dependencies
handling, integrating new recipes, recipes tweaks etc.

We are evaluating the possibility to migrate to Yocto Project (Openembedded
Core). But some requirements MUST be met:

   - eglibc (2.12), gcc (4.5.3), u-boot, kernel and other packages versions
   must have be maintained. We cannot update it versions since this product is
   in the field for a couple of years and it was heavily tested and certified.


I read some guidelines[1][2], but my main concern is if I'm going into a
"can of worms", as most packages dating from 2011 and I do not know how
much the OpenEmbedded-core is "coupled" to glibc and gcc versions, for
example.


I think the ideal scenario is to use the most recent Yocto version and have
all nice features available. Perhaps to achieve this I have to migrate
first to "2011-1" branch of openembedded-core and have all packages
versions and custom modifications ported to the new openembedded platform
and then migrate to the a newer version.



I really appreciate if you guys have some thoughts, tips or some kind of
information that can help me to take this decision and move forward.



[1]
http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#migration
[2] http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core



Regards,

--
*dS
Diego Sueiro

Administrator of Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

[-- Attachment #2: Type: text/html, Size: 2354 bytes --]

Re: Migrate, or not Migrate, that's the question!!!

[Bryan Evenson]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

Diego,

In my opinion, I think in the long term it would be easier to make a clean break.  Start with a recent branch, like Jethro, get a minimal image to build for your hardware and then add your own layer with your proprietary recipes.  I think that will be a lot easier than trying to get oe-core working with 5+ year old versions of gcc and eglibc.  Yes, that would mean additional testing, but it may be less testing/integration than you are currently doing just trying to keep your current image maintained.

Regards,
Bryan

From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Diego Sueiro
Sent: Monday, January 25, 2016 4:41 AM
To: yocto@yoctoproject.org
Subject: [yocto] Migrate, or not Migrate, that's the question!!!

Hello folks,


I'm in a project that uses openembedded-classic and Arago stuff to build the product's image.
A lot of problems have been raised in relation to build time, dependencies handling, integrating new recipes, recipes tweaks etc.

We are evaluating the possibility to migrate to Yocto Project (Openembedded Core). But some requirements MUST be met:

  *   eglibc (2.12), gcc (4.5.3), u-boot, kernel and other packages versions must have be maintained. We cannot update it versions since this product is in the field for a couple of years and it was heavily tested and certified.

I read some guidelines[1][2], but my main concern is if I'm going into a "can of worms", as most packages dating from 2011 and I do not know how much the OpenEmbedded-core is "coupled" to glibc and gcc versions, for example.


I think the ideal scenario is to use the most recent Yocto version and have all nice features available. Perhaps to achieve this I have to migrate first to "2011-1" branch of openembedded-core and have all packages versions and custom modifications ported to the new openembedded platform and then migrate to the a newer version.



I really appreciate if you guys have some thoughts, tips or some kind of information that can help me to take this decision and move forward.



[1] http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#migration
[2] http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core



Regards,

--
*dS
Diego Sueiro

Administrator of Embarcados
www.embarcados.com.br<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

[-- Attachment #2: Type: text/html, Size: 9719 bytes --]

Re: Migrate, or not Migrate, that's the question!!!

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

Bryan,


On 28 January 2016 at 13:49, Bryan Evenson <bevenson@melinkcorp.com> wrote:

> In my opinion, I think in the long term it would be easier to make a clean
> break.  Start with a recent branch, like Jethro, get a minimal image to
> build for your hardware and then add your own layer with your proprietary
> recipes.  I think that will be a lot easier than trying to get oe-core
> working with 5+ year old versions of gcc and eglibc.  Yes, that would mean
> additional testing, but it may be less testing/integration than you are
> currently doing just trying to keep your current image maintained.
>
>
>

Thanks for your opinion.

But unfortunately, updating the packages is out of scope in this moment
since the product is certificated and doing this will require a new process.

Maybe I can use the Arago External Pre-built Binary Toolchain (2011-09)[1]
in which is supported by TI until daisy branch[2].


[1] -
http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html
[2] -
http://arago-project.org/git/?p=meta-arago.git;a=tree;f=meta-arago-extras/conf/distro/include;h=23e7bcba85ab80e4bf813fd43f64c61a12ba3f0a;hb=refs/heads/daisy


Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 2774 bytes --]

Re: Migrate, or not Migrate, that's the question!!!

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 2340 bytes --]


> On Feb 1, 2016, at 6:18 AM, Diego Sueiro <diego.sueiro@gmail.com> wrote:
> 
> Bryan,
> 
> 
> On 28 January 2016 at 13:49, Bryan Evenson <bevenson@melinkcorp.com <mailto:bevenson@melinkcorp.com>> wrote:
> In my opinion, I think in the long term it would be easier to make a clean break.  Start with a recent branch, like Jethro, get a minimal image to build for your hardware and then add your own layer with your proprietary recipes.  I think that will be a lot easier than trying to get oe-core working with 5+ year old versions of gcc and eglibc.  Yes, that would mean additional testing, but it may be less testing/integration than you are currently doing just trying to keep your current image maintained.
> 
> 
> 
> 
> Thanks for your opinion.
> 
> But unfortunately, updating the packages is out of scope in this moment since the product is certificated and doing this will require a new process.

I think you have to think about what you are getting into. You are trying to mix quite two different things are create third one. If I were you, I would just
keep myself synced with upstream as much as I could, Don’t look one way, you have to look into time and effort you will spend on maintaining this new
jargon for years to come.

> 
> Maybe I can use the Arago External Pre-built Binary Toolchain (2011-09)[1] in which is supported by TI until daisy branch[2].
> 
> 
> [1] - http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html <http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html>
> [2] - http://arago-project.org/git/?p=meta-arago.git;a=tree;f=meta-arago-extras/conf/distro/include;h=23e7bcba85ab80e4bf813fd43f64c61a12ba3f0a;hb=refs/heads/daisy <http://arago-project.org/git/?p=meta-arago.git;a=tree;f=meta-arago-extras/conf/distro/include;h=23e7bcba85ab80e4bf813fd43f64c61a12ba3f0a;hb=refs/heads/daisy>
> 
> 
> Regards,
> 
> --
> *dS
> Diego Sueiro
> 
> Administrador do Embarcados
> www.embarcados.com.br <http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>
> 
> /*long live rock 'n roll*/
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


[-- Attachment #1.2: Type: text/html, Size: 4367 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: Migrate, or not Migrate, that's the question!!!

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

Khem,

On 1 February 2016 at 18:34, Khem Raj <raj.khem@gmail.com> wrote:

>
> I think you have to think about what you are getting into. You are trying
> to mix quite two different things are create third one. If I were you, I
> would just
> keep myself synced with upstream as much as I could, Don’t look one way,
> you have to look into time and effort you will spend on maintaining this new
> jargon for years to come.
>

Thanks for your opinion.

I agree with you, but this decision is out of my responsibility.

We already had problems on backporting device drivers and packages.
I believe that for the next generation of the product we'll try to keep
synced with upstream, but until then I want to try to use a recent version
of Yocto/OE.


Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 1751 bytes --]

Re: Migrate, or not Migrate, that's the question!!!

[Diego Sueiro]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On 2 February 2016 at 08:40, Diego Sueiro <diego.sueiro@gmail.com> wrote:

> Khem,
>
> On 1 February 2016 at 18:34, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> I think you have to think about what you are getting into. You are trying
>> to mix quite two different things are create third one. If I were you, I
>> would just
>> keep myself synced with upstream as much as I could, Don’t look one way,
>> you have to look into time and effort you will spend on maintaining this new
>> jargon for years to come.
>>
>
> Thanks for your opinion.
>
> I agree with you, but this decision is out of my responsibility.
>
> We already had problems on backporting device drivers and packages.
> I believe that for the next generation of the product we'll try to keep
> synced with upstream, but until then I want to try to use a recent version
> of Yocto/OE
>


And just to keep it clear. We are talking about a project with 272 packages
and 1.5 MLOC (proprietary embedded code) which took 4 years to be developed.


Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br
<http://www.embarcados.com.br/?utm_source=assinatura_diego&utm_medium=e-mail&utm_campaign=Assinatura%20Email%20Diego>

/*long live rock 'n roll*/

[-- Attachment #2: Type: text/html, Size: 2270 bytes --]