Re: [PATCH 2/6] classes/*_rpm: integrate Smart into RPM filesystem construction

[Paul Eggleton <paul.eggleton@linux.intel.com>]

On Thursday 06 December 2012 15:31:26 Richard Purdie wrote:
> On Tue, 2012-12-04 at 13:49 -0600, Mark Hatle wrote:
> > From: Paul Eggleton <paul.eggleton@linux.intel.com>
> > 
> > Use Smart to construct the root filesystem for images and the contents
> > of SDKs rather than the custom scripts around rpm we had previously.
> > This ensures the result when producing an updated image will be the
> > same as upgrading to the same package versions from an older image on
> > the target, as well as allowing us to remove a substantial amount of
> > code making the rpm classes much easier to follow.
> > 
> > Some bugfixes from Bogdan Marinescu <bogdan.marinescu@intel.com>.
> > SDK implementation and testing as well as a number of bugfixes from
> > Mark Hatle <mark.hatle@windriver.com>.
> > 
> > Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> > Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> > ---
> > 
> >  meta/classes/package_rpm.bbclass      |  533
> >  ++++++--------------------------- meta/classes/populate_sdk_rpm.bbclass
> >  |   48 +---
> >  meta/classes/rootfs_rpm.bbclass       |   31 +-
> >  3 files changed, 117 insertions(+), 495 deletions(-)
> > 
> > diff --git a/meta/classes/package_rpm.bbclass
> > b/meta/classes/package_rpm.bbclass index 200a941..aa5b156 100644
> > --- a/meta/classes/package_rpm.bbclass
> > +++ b/meta/classes/package_rpm.bbclass
> > @@ -8,6 +8,8 @@ RPMBUILD="rpmbuild"
> > 
> >  PKGWRITEDIRRPM = "${WORKDIR}/deploy-rpms"
> >  PKGWRITEDIRSRPM = "${DEPLOY_DIR}/sources/deploy-srpm"
> > 
> > +EXTRANATIVEPATH += "python-native"
> > +
> 
> Er, no!
> 
> Why do we need to do this? We now need python-native at package
> generation time? Why?

Sorry, I meant to come back to this before submitting; the reason I added it 
was so that smart can find its python modules that get installed into the 
native sysroot (which I was surprised to find that the setup did not allow it 
to do out of the box, frankly). I'm sure there is a much better way to handle 
this though - we only actually need the path to be accessible within 
do_rootfs.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre