[yocto] can not build yocto on NFS mounted NAS

[lothar at denx.de]

Am 2013-08-21 07:58, schrieb Robert Berger:
> Hi,
> 
> On 08/20/2013 07:45 PM, lothar at 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 at 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