All of lore.kernel.org
 help / color / mirror / Atom feed
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
>
>


  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.