From: Saul Wold <sgw@linux.intel.com>
To: yocto <yocto@yoctoproject.org>
Subject: Re: Web Hob - two additional design ideas
Date: Wed, 27 Jun 2012 14:03:30 -0700 [thread overview]
Message-ID: <4FEB7522.5080202@linux.intel.com> (raw)
In-Reply-To: <CDED78A957032E45B3239CDDA7642D151C8681AA@ORSMSX105.amr.corp.intel.com>
On 06/27/2012 12:17 PM, Stewart, David C wrote:
> Gang - there are a couple of ideas for Web Hob that we have talked about. I don't remember seeing them in the various movies and documents. So I'm going to throw them out there to get your feedback and hopefully get them in the design.
>
> * Visualizing the image
>
> One of the things which frustrates me about GUI tools which build Linux images is that you usually get a long list of packages to choose from, but no real guidance. I think there are a couple of interesting ways to visualize what is in the image.
>
> One would be to add more visual information about what makes up the image, maybe like a pie chart or linear chart which shows the breakdown between kernel, libraries, commands; perhaps with some drill down into these categories to show which libraries, for example. This could be extremely useful for tuning a poky-tiny image for its footprint size.
>
This could be interesting for larger images where we could make use the
the "SECTION" metadata, but might be more of a challenge for a meta-tiny
where all you really have is libc (of some flavor) and busybox.
There may be additional metadata to help with the drill down further
than maybe 1 level.
> I find I'm also struggling with figuring out how to add a whole subsystem, rather than picking out the packages. This goes beyond the scroll list of packages to add higher-level groups of packages. This might be already present in how we present Tasks to select, so it might already be there.
>
We need to work on renaming the existing task-* recipes to make it more
understood as package grouping or <pick your descriptive name here>
> * Finalizing your device's source offer
>
> One of the things the Project has been praised on is our support for building license compliant embedded distributions. This turns out to be one of the biggest challenges when people use Linux for their embedded devices - often the Linux gets shipped out on the embedded device, but the sources are not made available as specified in the GPL. Through our tracking and validating of source licenses in recipes, the logic in the build system to restrict licenses used, and the source manifests generated in the build, I think we have a world class solution. This really needs to be supported well in Web Hob.
>
> So the requirement here is that when a build is completed, you not only get access to the image (and kernel) but maybe also a tar file of the sources and scripts used to build the image, for purposes of GPL license compliance.
>
I want to point out to the designers and implementers that there already
exists a mechanism to archive various levels of source, source with
logs, source with logs and scripts, ... Please review the
archiver.bbclass so we do not re-invent the wheels for the underlying
implementation of what Dave is asking for. We just need to inherit that
class and set the appropriate flags for what level of archiving.
This should also include a License Manifest of some sort that could be
suitable for posting on a website, I am not sure if this is something
Beth already has plans for in her license work.
Sau!
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
next prev parent reply other threads:[~2012-06-27 21:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 19:17 Web Hob - two additional design ideas Stewart, David C
2012-06-27 21:03 ` Saul Wold [this message]
2012-06-28 9:33 ` Barros Pena, Belen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FEB7522.5080202@linux.intel.com \
--to=sgw@linux.intel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.