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

List:       openembedded-architecture
Subject:    Re: [Openembedded-architecture] OEDEM - Setup program
From:       Denys Dmytriyenko <denis () denix ! org>
Date:       2016-10-18 21:25:43
Message-ID: 20161018212543.GO2494 () denix ! org
[Download RAW message or body]

Trevor,

Mark's tool DOES use repo - that's one of the legal holdups for upstreaming 
the corresponding patches used by the tool...

-- 
Denys


On Tue, Oct 18, 2016 at 05:18:40PM -0400, Trevor Woerner wrote:
> 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
> 
_______________________________________________
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]