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

[Jeremiah Foster]

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.


>
> 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
comes with upstream maintainer information, and you know it is Open Source
(since Debian created the Open Source definition.)

- 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.

>
> - 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.


> 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.
> >
> >
> > Cheers,
> >
> > Jeremiah
>
> [1] https://github.com/meta-debian/meta-debian
>
> - Gunnar
>
> --
> Gunnar Andersson
> Lead Architect, GENIVI Alliance
> Infotainment, Volvo Car Corporation
>
>
Regards,

Jeremiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/automotive-discussions/attachments/20150612/7985e555/attachment-0001.html>