[agl-discussions] Meta-debian (was: SOTA)

Andersson, Gunnar gunnar.x.andersson at volvocars.com
Fri Jun 12 13:31:36 UTC 2015


> On Fri, Jun 12, 2015 at 1:06 PM, Andersson, Gunnar <gunnar.x.andersson at volvocars.com> wrote:
>> From: ... On Behalf Of Jeremiah Foster
>> Sent: den 8 juni 2015 12:00
>> To: Pete Popov
>> Cc: genivi-projects at lists.genivi.org; automotive-discussions at lists.linuxfoundation.org
>> Subject: Re: [agl-discussions] SOTA
>
> [trimmed]
>
>> Interesting subthread about "Debian vs. embedded".  I took out one
>> part of it:
>
>>> What is the point then of using Yocto if all you get
>>> is an unsupported blob of code without the latest middleware and
>>> frameworks? I think this is why companies like Hitachi are moving to
>>> using Yocto with Debian (i.e. meta-debian) because you get a distro at
>
>> Toshiba. See [1]
>
> Excuse me, you're right; its Toshiba.
>
>
>> I wonder how you conclude that this is a company strategy ("moving
>> to").  Do you know this?  Otherwise it seems speculative considering it's
>> just a Github repo - this could be some R&D office investigation or some
>> individual's pet project, who knows?
>
> Because I spoke with them after ELC and in person in Japan and asked if
> this is going to be a product. The three developers, or two developers
> and one manager, I spoke with stated that they intend to use this for a
> Vehicle to Infrastructure product. They've had discussions with Debian's
> kernel maintainer (Codethink's Ben Hutchings) who advised them on an
> approach with regard to the long term supported Debian kernel and how to
> engage with mainline development.

The plot thickens.  :)

Kernel strategy is only a small aspect though, but maybe Codethink has 
an interesting opinion to add overall?

>
>
>> Personally I can't fully wrap my head around it - it's not stated what they
>> want to achieve, what they expect to get as technical advantages. The only
>> stated goal is "using Debian source packages".
>>
>> It forces me to speculate about advantages of using those:
>>
>> - Uniform location of sources? I.e. you could assume the source is
>> always available at a URL like <debian-mirror/<release>/<packagename>
>
> Plus the canonical source location itself can be trivially mirrored and

I'd say all the used sources in a Yocto/poky build can be trivially mirrored,
even if stored in different places. I was rather thinking that this would be
one small advantage for creating generic recipes.

But it is an advantage to be able to fetch from many mirrors (before you 
have created your own local mirror), and Debian certainly provides that!

> comes with upstream maintainer information

Good to have I suppose.  I'm not familiar with how/if this matches 
other alternatives?

>, and you know it is Open Source (since Debian created the Open Source
>definition.)

Awesome!  :-D 
But I'd suspect anyone serious about building a system need to study 
the license of all included software carefully anyhow. If nothing else 
to ensure license compliance.

>>
>> - Generic build scripts (every source package should look similar since
>> it is .deb packaged?)
>
> In discussions with the Toshiba guys it turns out that this is not so
> easy. There is not a simple mapping from one Debian's build system to
> Yocto's.

OK, I guess that is what I'm seeing then, so that advantage is lost.  
I suppose they consider the other advantages to be enough then I 
presume.  I'm not convinced yet.

>
>> - The distro is a collection of component versions that are compatible
>> with each other, evidenced by all the testing done in the Debian
>> ecosystem.   (This should be a fairly big one.)
>>
>> - Easy and frequent version and security updates - just follow the
>> Debian releases.  (I'm still wondering if this translates in practice.)
>>
>> I'm far from a Yocto expert but have a fair experience. Looking into the
>> recipes I can't figure out the pattern they want to follow, and I can't
>> really identify that they are meeting those advantages successfully.
>> Some scripts look like they *could* be very generic but aren't.
>>
>> Are these bb files not a bit strange and not that professional, or is
>> that my limited experience not seeing it?
>
> I can't gauge their Yocto experience, however I pointed them to some
> Debian tooling that they did not know about. If you have a lot of
> experience with using Debian on embedded platforms, some of the pointers
> I gave you would know about. So I cannot say with great confidence that
> they've used Debian in a product before. What that means for their Yocto
> experience I don't know.

I see.  The key question is again if Yocto buys you anything compared to
just using those tools then.

- Gunnar

>>
>> It doesn't look right to me.  They don't seem to use the PV variable!
>> There are specific package versions hard coded in each file at the
>> wrong place?  Am I misinterpreting - maybe some other really
>> experienced yocto devs can provide their opinion please.
>>
>> I guess I don't see the consistent patterns I would have expected.
>> The files include a lot more text than I thought - I would imagine lots
>> more generic scripts - I expected a recipe to just define the name of
>> the package and then basically defer all work to a generic build script
>> in order to make use of consistency that Debian defines.
>> *That* would have scaling advantages. By convention the generic file
>> would know where the sources are stored, how to build them, and
>> so on.  But there are apparently a lot of Debian-provided patches
>> that need to be stored and applied too.  Possibly there's a more
>> effective way than the way most Yocto projects do, to manually put
>> them under files/ and refer to them one by one in the recipe?
>>
>> The associated scripts directory also does not publish any
>> Automation tools that would create bb files directly from some
>> Debian input, which would be an alternative way to go.
>>
>> So the whole project looks a little crazy to me if scaling advantages are
>> not met - I would then rather say if you want to go Debian you'd be
>> better off going full Debian instead.
>>
>> There might be something here of value but I'm far from sure at this
>> point. I would hope someone could explain the developers strategy,
>> intention and way to go about it, because the docs are not clear enough.
>>
>>> the end of your build that has all its packages supported out-of-the-box.
>>
>> Except that the way it is done now it looks like a lot of manual work to
>> have all Debian packages out-of-the-box, and then to keep them
>> maintained. Maybe I'm missing something.
>
>> Has anyone else looked at that repo [1] and have any insight to share?
>>
>>> You want support for poky you're going to have to buy it.
>>>
[...]

-- 
Gunnar Andersson
Lead Architect, GENIVI Alliance
Infotainment, Volvo Car Corporation



More information about the automotive-discussions mailing list