Bug 6463 - oe-core: create a meta binary package for the image recipe
Summary: oe-core: create a meta binary package for the image recipe
Status: RESOLVED WONTFIX
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.7
Hardware: x86 Multiple
: Low enhancement
Target Milestone: 1.7 M3
Assignee: Robert Yang
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2014-06-18 07:35 UTC by Robert Yang
Modified: 2014-09-30 05:37 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Yes (doc changes required)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Yang 2014-06-18 07:35:03 UTC
Cuerrently, the recipe image such as core-image-sato.bb doesn't generate a rpm package, it would help if we have a core-image-sato.rpm which contains the following info:

1) Put the IMAGE_INSTALL to the Requires section of the rpm.
2) Add the ROOTFS_POSTPROCESS_COMMAND to the "postinst" section of the rpm.

The problems is that we are trying to use a third part installer to install the rpms, it's easy to get the IMAGE_INSTALL, but not easy to get the ROOTFS_POSTPROCESS_COMMAND and make it run out of oe atm.
Comment 1 Paul Eggleton 2014-06-19 15:00:04 UTC
So Richard and I have looked at this and whilst it is inventive, we're not completely convinced. I certainly think this behaviour should not be on by default.

FWIW, the data you're requesting is available through buildhistory, although it's possible that having to enable that would not be desirable for this.
Comment 2 Robert Yang 2014-06-19 15:23:37 UTC
(In reply to comment #1)
> So Richard and I have looked at this and whilst it is inventive, we're not
> completely convinced. I certainly think this behaviour should not be on by
> default.
> 
> FWIW, the data you're requesting is available through buildhistory, although
> it's possible that having to enable that would not be desirable for this.

Thanks for the comment, I will refer to buildhistory.
Comment 3 Robert Yang 2014-07-02 05:19:38 UTC
(In reply to comment #1)
> So Richard and I have looked at this and whilst it is inventive, we're not
> completely convinced. I certainly think this behaviour should not be on by
> default.

Hi Paul,

I'v nearly finished the code, the only different is that you suggested not create it by default, but it seems that not create it by default would make the code more complicated, I will send the patches sooner.

> 
> FWIW, the data you're requesting is available through buildhistory, although
> it's possible that having to enable that would not be desirable for this.