On 11/27/2014 02:17 PM, Richard Purdie wrote:
On Thu, 2014-11-27 at 05:02 -0700, Gary Thomas wrote:
On 2014-11-27 01:35, Mike Looijmans wrote:
Here's an example recipe to demonstrate the issue. Save it as "deployme.bb"
into a recipe dir. Then build it for two machines. Building it for one machine will
remove it from the
deployment directory of the other. This problem has been bugging me for months, I had
files just "disappear" mysteriously from the deploy directory and seemingly
random times, and
now I finally figured out what causes it.
(cut here)
SUMMARY = "Demonstrate a bug in OE deployment"
DESCRIPTION = "Build this package for a machine X, then look at the image's \
deploy directory. You'll see a deployme.txt there. Now build it for another \
machine, e.g. "Y". The deployme.txt for machine X will have disappeared \
from the image dir. This appears to be a bug in OE's deployment."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
inherit allarch deploy
do_compile () {
echo "Hello world!" > deployme.txt
}
do_deploy () {
install -d ${DEPLOYDIR}
install -m 644 ${B}/deployme.txt ${DEPLOYDIR}/
}
addtask deploy before do_build after do_compile
(cut here)
Very interesting & verified with the latest master.
Have you filed a bug? https://bugzilla.yoctoproject.org/
Well, I'm not convinced this is a bug as such. You've created an
"allarch" deploy task, how would you expect this to behave?
"allarch" means that the output from this task is universal and can be
used on all targets. It will therefore get run once.
A "deploy" task is machine specific.
What ends up happening is therefore the task has a stamp is
"universally" created. When you change machine, the checksum of the task
changes, the previous version is removed, the new version is installed.
So in many ways the system is doing exactly what I would expect it to do
and it isn't a bug in that sense.
It's not a bug in the sense that it doesn't do as it was programmed to do. I
understand what's happening here.
I just think that the logic here is wrong. If "deploy" is machine specific,
then the implicit "undeploy" should be machine specific too, right?
The real question is how should an "allarch" + "deploy" task behave when
you've specified machine specific paths? Perhaps erroring would be
better?
That would mean that roughly all deploy tasks will fail. At best they're tied
to MACHINE_ARCH, but never to MACHINE itself.
Would be strange to put PACKAGE_ARCH="${MACHINE}" in a recipe that clearly has
no dependency on machine specific things. And I wrote "${MACHINE}" here on
purpose.
I was thinking along the lines of "DEPLOY_DIR_IMAGE must have the same prefix"
or so.
If I knew the solution, I'd have posted a patch instead of a question or report.
M.
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: [email protected]
Website: www.topic.nl
Please consider the environment before printing this e-mail
Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
