<div dir="ltr">On 1 February 2018 at 14:39, Alexander Kanavin <span dir="ltr"><<a href="mailto:alexander.kanavin@linux.intel.com" target="_blank">alexander.kanavin@linux.intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/01/2018 01:36 PM, Mauno Niko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Before we can declare that, we need to look what comm is actually used<br>
for during build, and why its absence is not a problem and doesn't cause<br>
errors.<br>
<br>
Consider also that using comm from host may break reproducibility, if<br>
absence or presence of comm on the host results in a different output<br>
from the build.<br>
</blockquote>
<br>
My patch initially did add coreutils-native to u-boot DEPENDS.<br>
<br>
Should I resubmit it? (did not apply due to mismatch in recipe filename (version))<br>
</blockquote>
<br></span>
RP has already merged the patch you sent, I think :)<br>
<br>
Still, in my opinion - yes, it's better to undo the HOSTTOOLS change, and add coreutils-native. But first, research a bit further for what purpose comm is used during build and why its absence doesn't break it.<br></blockquote><div><br></div><div>coreutils is on 100% of linux desktops (rounding up), and this would be the only recipe to build-depend on coreutils-native. I don't see the problem with depending on the host for this.</div><div><br></div><div>Ross </div></div></div></div>