[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-architecture
Subject:    Re: [Openembedded-architecture] OEDEM - Setup program
From:       Trevor Woerner <twoerner () gmail ! com>
Date:       2016-10-18 21:18:40
Message-ID: 20161018211840.GA24493 () openSUSE-i7 ! site
[Download RAW message or body]

A number of people/projects have been bandying about a number of solutions to
this same question for a couple years now [1].

In other words: several people/projects have independently come to the
conclusion that some tool was needed to help people put together and clone
various layers. This tool would come before bitbake in a user's workflow.

I'm happy to see Mark's tool come to light. In my opinion, it would be nice to
see the community hone in on one tool rather than continue their separate
paths. This would happen faster if the tool came under the project's umbrella
(alongside the other tools like bitbake, toaster, crops, devtool, etc). Also,
a common tool would get better documentation, better support, and is more
likely to be better maintained over time. But we have to make sure it's a tool
the community is going to get behind and support!

From what I can tell all these tools have the same goals in common. How they
differ is based on:

1) whether they use a repo manifest or simply clone layers "by hand"

2) whether they interrogate the layerindex for layer information or simply
   grep through whatever layers the script finds "beneath" it in the directory
   structure (which are pulled/cloned from earlier in the script)

3) whether the tool uses a quasi-graphic interface (dialog/whiptail) or the
   plain cmdline (some tools let you choose or will look for one, fall back,
   look for another, then fall back to the cmdline if "graphical" options
   aren't available)

A tool that uses repo introduces another tool (and possibly another workflow)
for the user to learn (i.e. Android's repo). But it allows the creators much
better control over the possibility of success for the build. In other words,
if I know that <these> checkouts of <those> repositories are going to work
well together then I can just pin <those> specific repositories at <these>
specific HEADs, and everything should work.

A tool that interrogates the layerindex allows the creators of the tool to not
have to guarantee any specific build or MACHINE. In other words it becomes
more flexible. A tool that uses the layerindex is less likely to die from
bitrot; if a new MACHINE/layer/distro/whatever is added to the layerindex in
the future, no changes are needed to the tool to take advantage of this new
thing. But the success of the build relies much more heavily on the quality of
the metadata in the layerindex.

A tool that uses the repo method needs more maintenance as time goes on. A
tool that simply pulls its information from the layerindex only needs to be
updated if the layerindex's REST API changes.

A tool that relies exclusively on the layerindex ignores local layers. If the
user has their own in-house custom layers, there needs to be a way to pull
them into the layer setup too (although these could be added later by hand).

What ends up happening is that the repo-based tools lend themselves to
projects that are trying to build distributions for a given (static) set of
boards/MACHINEs. The layerindex tools lend themselves to situations where a
person just wants to create an image for a specific board.

In the end they're all attempts at creating a cmdline version of toaster ;-)


From what I can tell, Mark's tool doesn't use repo, gets its layer information
from the layerindex, and doesn't use any fancy "graphics" tool. What's also
interesting about Mark's tool is that it only tries to be a layer setup tool;
most of the other tools also try to help the user configure their build after
the layer's are chosen and cloned.



...just my 2 cents...




[1] This is the history as I know it, I'm sure others can chime in with more
details:

- a long time ago angstrom used a custom script to pull its layers together
  (pre-2011?) (setup-scripts?)
- the Freescale community created their "setup-environment" script (2012):
  https://github.com/Freescale/fsl-community-bsp-platform
- I created my own "oe-layerindex-config" (2015)
  https://github.com/twoerner/oe-layerindex-config
  which was a proof-of-concept tool to use "dialog" to allow a user to select
  layers from the layerindex and configure for a build
- some Linaro people were interested in some of the ideas from
  oe-layerindex-config (dialog) combined with angstrom's setup-scripts but
  weren't interested in pulling metadata from layerindex so they created the
  oe-rpb-manifest https://github.com/96boards/oe-rpb-manifest
  (this comes from angstrom's scripts, so in the git history it is old, but in
  reality the RPB stuff is from 2015)
- I liked the oe-rpb-manifest but wanted to add the ability to use any of
  dialog, whiptail, or the cmdline so I created oe-repo-config (2015)
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
[prev in list] [next in list] [prev in thread] [next in thread]