Am 2013-08-21 07:58, schrieb Robert Berger:
Hi,
On 08/20/2013 07:45 PM, lot...@denx.de wrote:
Hi,
I have just two points here to ask:
1) Wouldn't simply using SSTATE_MIRRORS be a better solution here,
instead?
It's not the same.
SSTATE and DL_DIR are on an nfs export anyhow and this works.
The problem here is with TMP dir (and an nfs server with a funny
underlying filesystem like UFS) and hard links.
2) Patch: wouldn't it be nicer to try the cp -al, and catch the
CalledProcessError Exception, if it is thrown, and then run the brute
force cp -a? Perhaps even as a general approach?
In theory yes, in practice you will find out that if you build
something
like core-image-sato-sdk "cp -al" is not the only place which creates
hard links.
Regards,
Robert
..."There's an infinite number of ways to make a simple problem seem
difficult; only a handful to make a difficult problem seem simple" -
Jack Crenshaw's Law #1
My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Hi Robert,
Thank you for the answer. About my second point, I think you
missunderstood, or I do not get your answer correctly, respectively.
In brief, I mean:
TRY.... CATCH... EXCEPTION
In detail:
The issue you discovered here, IMHO is definitely a real problem, when
it comes to do hardlinks across filesystems.
Grepping for 'cp -al', though, to me only reviels this single place
where hardlinks are done (do you know more?), which I showed you in the
chat we had apart and for which you posted the fix here in the ML. To my
understanding, it is only used by the sstate .bbclass, to refer to the
build products after recipe execution. Means, say, using for instance a
central SSTATE_DIR folder, you may remove the 'tmp' folder in a
particular build folder (referring to the SSTATE_DIR), and still be able
to build in your other build folders (having set SSTATE_DIR) relatively
fast, since the build products were referenced in SSTATE_DIR by
hardlinks. This is done by this 'cp -al', which is applied to every
single recipe's build, means it is pretty central!
Thus, simply exchanging 'cp -al' by 'cp -a' would affect all recipes'
execution. But running 'cp -al' and extending it by a fallback to 'cp
-a' using the already thrown EXCEPTION, does not change the original
behavior, but extends it. Perhaps this remark seems a bit hairsplitting.
Ok, but, not handling any exception here, IMHO seems to be wrong, too,
since it will already be thrown. And if so, it should be fixed, or not?
This was my point about. Keeping in mind that if both approaches fail,
there could be at least e.g. printstacktrace() like output..
AFAIR, the git fetcher uses a similar fallback approach for handling
unaccessable repositories.
Just some remarks, maybe I'm wrong.. but, also currently messing a bit
with sstate.
BR,
Lothar Rubusch
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
