From: Gary Thomas <gary@mlbassoc.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: image.bbclass vs core-image.bbclass
Date: Fri, 17 Jul 2015 05:30:12 -0600 [thread overview]
Message-ID: <55A8E744.3060509@mlbassoc.com> (raw)
In-Reply-To: <2990247.hoeDgcCp8y@peggleto-mobl.ger.corp.intel.com>
On 2015-07-17 05:14, Paul Eggleton wrote:
> Hi Gary,
>
> On Friday 17 July 2015 04:56:43 Gary Thomas wrote:
>> Why are some ROOTFS_POSTPROCESS_COMMANDs being set in image.bbclass
>> and others in core-image.bbclass? If I build an image using only
>> image.bbclass, I miss the settings from core-image.bbclass (which
>> is somewhat misnamed IMO since it's heavier than image.bbclass)?
>>
>> Is there some reason not to have all of the ROOTFS_POSTPROCESS_COMMANDs
>> just in image.bbclass alone?
>
> The existence of this class is kind of a legacy from when parts of Poky became
> OE-Core - originally core-image.bbclass was called poky-image.bbclass, and
> what was in it was specific to Poky. We had to bring it over though because all
> of our example images, which we need to have for verification (if nothing
> else), inherited from it and still do. We've made minor adjustments to core-
> image.bbclass since then but there are still things in there that are clearly
> "distro" type definitions that don't make sense for everyone; so far nobody has
> really stepped up to find any better common items or reasonable defaults
> (perhaps there aren't any, though I doubt that).
>
> There is a bug open assigned to me to try to sort this out, but to be honest
> I've been struggling with how to best to do it:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5424
>
> I'm open to any suggestions, because I do think the dichotomy between these
> classes ought to be resolved if it can be done practically.
>
> Specifically on the ROOTFS_POSTPROCESS_COMMANDs, those do look like they ought
> to somehow be in image.bbclass if they can be added in a manner that doesn't
> interfere with people's ability to create images that aren't rootfses.
It seems that many of the ROOTFS_POSTPROCESS_COMMANDs in image.bbclass already
assume that a rootfs is being built.
To me the ROOTFS_POSTPROCESS_COMMANDs that are in core-image.bbclass
don't seem any more invasive than the ones in image.bbclass. For starters,
I'd like to see them moved to image.bbclass. It's also quite strange that
the read-only-rootfs hook is defined in image.bbclass but only invoked
from core-image.bbclass?? [That's the one that lead me down this road]
Any objections to a patch that does that?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
next prev parent reply other threads:[~2015-07-17 11:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-17 10:56 image.bbclass vs core-image.bbclass Gary Thomas
2015-07-17 11:14 ` Paul Eggleton
2015-07-17 11:30 ` Gary Thomas [this message]
2015-07-17 12:37 ` Paul Eggleton
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=55A8E744.3060509@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/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.