<div dir="ltr"><div dir="ltr">Would it make sense to at least as temporary work around add a flag saying that git-lfs does or doesn't exist in HOSTTOOLS after it being added to HOSTTOOLS_NONFATAL and then let those few recipes which already use git-lfs to check this flag and fail early with meaningful error message about git-lfs? It can be in a bbclass so that all recipes can easily share it and it can be later changed to add dependency on git-lfs-native (if there is one later).</div><div dir="ltr"><br></div><div>Only issue is that people will forget to inherit this bbclass in their recipes if it just happen to work.</div><div><br></div><div>Adding it to some subdirectory inside HOSTTOOLS which is added to PATH only when the bbclass is inherited might be a bit too much for just a work around :/.</div><div><br></div><div>Regards,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 17, 2019 at 12:25 PM Adrian Bunk <<a href="mailto:bunk@stusta.de">bunk@stusta.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Apr 17, 2019 at 09:57:50AM +0000, Bach, Pascal wrote:<br>
> > > > Your "everyone has to install it" worry misses the much bigger<br>
> > > > problem that git-lfs is a relatively new tool and not available in<br>
> > > > distributions like Debian 9 or Ubuntu 16.04.<br>
> > ><br>
> > > Someone could certainly write a native recipe for lfs and add that as<br>
> > > a dependency which would also solve this problem. I'd be quite happy<br>
> > > to see that and it would neatly solve the problems.<br>
> > <br>
> > This was also my first thought.<br>
> > <br>
> > It stops being neat once you realize that it requires packaging a 3 digit<br>
> > number of Go libraries.<br>
> <br>
> I don't think that's how go packaging works. Go usually statically links everything at compile time and bundles the sources with modules.<br>
<br>
It is not really static linking, it is more like the "libraries" being <br>
source files instead of compiled code.<br>
<br>
> So from a yocto point of view you only need to create one recipe with everything inside.<br>
<br>
Fetching from 100 different git repositories would be plenty of<br>
work to setup and to maintain, no matter how many recipes you use.<br>
<br>
Certainly not impossible, but I wouldn't call this neat.<br>
<br>
>...<br>
> Pascal<br>
>...<br>
<br>
cu<br>
Adrian<br>
<br>
-- <br>
<br>
"Is there not promise of rain?" Ling Tan asked suddenly out<br>
of the darkness. There had been need of rain for many days.<br>
"Only a promise," Lao Er said.<br>
Pearl S. Buck - Dragon Seed<br>
<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>