RFC: make do_deploy operate on packages instead of ${S}

RFC: make do_deploy operate on packages instead of ${S}

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Richard recently merged packaged-staging2, which highlighted a
fundamental problem in how we implement do_deploy.

But let me define do_deploy first:

  do_deploy puts files somewhere in ${DEPLOY_DIR} for the users
convenience and/or for further do_deploy steps.

With packaged-staging2 all build steps of recipes in DEPENDS are skipped
except for do_populate_staging, which in essence only unpacks an
archive. Which means do_deploy can't fish in ${S} anymore to find the
stuff it needs.

If we look at two of the heaviest do_deploy users (linux kernels and
uboot) we see than do_deploy can be implemented by unpacking the
kernel-image and u-boot packages.  If it would need files that aren't
packaged for good reasons, those files should be moved to staging and
accessed from there.

Note that these problems only surface when doing a clean build using
existing packages and pstage packages. The first build will succeed
because staging hasn't been packaged yet.

Comments?

regards,

Koen

- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHV+bLMkyGM64RGpERAo2rAJ4glb/q44M65LTJj5PgrnrN1p1EMACaAxAZ
XEYFjIgo2fvcq5A1yDw69oo=
=Bwg0
-----END PGP SIGNATURE-----

Re: RFC: make do_deploy operate on packages instead of ${S}

[Paul Sokolovsky]

Hello Koen,

Thursday, December 6, 2007, 2:10:51 PM, you wrote:

> Hi,

> Richard recently merged packaged-staging2, which highlighted a
> fundamental problem in how we implement do_deploy.

[]

> If we look at two of the heaviest do_deploy users (linux kernels and
> uboot) we see than do_deploy can be implemented by unpacking the
> kernel-image and u-boot packages.  If it would need files that aren't
> packaged for good reasons, those files should be moved to staging and
> accessed from there.

  This is apparently good thing. And it reminds me of another issue
I've been keeping in mind for long time: can we stop to suffix
deployed kernel by the build date and instead use PR? That would make
sure that a kernel built under same condition is name the same way.
And any change to build conditions (e.g. defconfig change) should lead
to bumping of PR anyway.

  This would make kernel image naming a bit inconsistent with rootfs
naming, but real problem here is that using build date for rootfs
suffix is not ideal too. I'll leave this topic for later time, after
hopefully this zImage naming is discussed.


> Note that these problems only surface when doing a clean build using
> existing packages and pstage packages. The first build will succeed
> because staging hasn't been packaged yet.

> Comments?

> regards,

> Koen




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com