[oe] Packaged Staging - 'Current' Status

[Richard Purdie]

On Thu, 2008-03-13 at 23:06 +0100, Koen Kooi wrote:
> Richard Purdie schreef:
> | As has been mentioned, I'm working on integrating packaged staging and
> | its about time I mentioned the current status. I say 'current' as it
> | applies to what I have offline, not what's in OE.dev.
> 
> I have a few questions that I can't deduce an answer to from your
> description:
> 
> ~ * How does packaged-staging handle switching ANGSTROM_MODE?
> 
> If the packaged-staging-packages (p-s-ps) get seperated by target tuple
> it should be ok, and if the p-s-ps dir can be overriden (e.g.
> PS_STAGING_DIR = foo/bar/${ANGSTROM_MODE}) we should be safe as well.

To lift code from my copy of the .bbclass:

PSTAGE_PKGVERSION = "${PV}-${PR}"
PSTAGE_PKGARCH    = "${MULTIMACH_ARCH}"
PSTAGE_EXTRAPATH  = ""
PSTAGE_PKGPATH    = "${DISTRO}${PSTAGE_EXTRAPATH}"
PSTAGE_PKGNAME 	  = "staging-${PN}_${PSTAGE_PKGVERSION}_${PSTAGE_PKGARCH}.ipk"
PSTAGE_PKG        = "${DEPLOY_DIR_PSTAGE}/${PSTAGE_PKGPATH}/${PSTAGE_PKGNAME}"

I'm 100% sure this isn't right yet :). The intent of PSTAGE_EXTRAPATH is
extra things needed can be injected by the distros. -cross and -native
are handled by the class itself appending the tmpdir path into that
variable (with / changed to -).

So yes, overrides are available but if we can make it work out the box
for everyone I will do that.

> ~ * do we have 'one' staging dir as we have now, or can each package have
> its own staging dir built from its DEPENDS?
>
> I know that this largely depends on how fast/well we debug sysroot
> stuff, but I'm curious how this is in your current design.

One staging dir at the moment. Multiple staging directories are a
headache for another time :).

> ~ * will p-s.bbclass be package format agnostic, or are we going to
> insist on opkg?
> 
> I know from experience that making it format agnostic isn't hard, only
> tedious, but most of all subject to combinatorial explosion for
> unit-testing. It also doesn't really matter, since p-s-ps are orthogonal
> to the ones in deploy, but I can image OE-newbies freaking out over this.

Good question. We're actually using so little of the package managers
features I'm nearly tempted to write something custom in python. The
benefit of that would be that no -native packages were needed as special
cases.

The current plan is to use ipkg/opkg and get something working, then
consider optimisations from there. I might find ipkg.py and rip that
apart...

Cheers,

Richard